| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-06-14 | |||
| 13:20:06 | mriedem | i see | |
| 13:20:07 | mriedem | "state":"active", "task_state":"pausing", "power_state":"running", | |
| 13:20:15 | mriedem | for instance.pause.start | |
| 13:21:05 | Kevin_Zheng | O we have state | |
| 13:21:33 | mriedem | Kevin_Zheng: yes i think that's the vm_state | |
| 13:21:52 | mriedem | i assume you're asking for something like the status in the rest api response for GET /servers/{server_id} which uses https://github.com/openstack/nova/blob/master/nova/api/openstack/common.py#L113 | |
| 13:22:08 | Kevin_Zheng | Yeah | |
| 13:22:23 | mriedem | i.e. https://developer.openstack.org/api-guide/compute/server_concepts.html | |
| 13:23:11 | mriedem | honestly i don't really know why there was ever a distinction in the rest api | |
| 13:23:25 | mriedem | i think the status field in the response predated the vm/task states being in the rest api response | |
| 13:23:45 | mriedem | which came in the OS-EXT-STS extension | |
| 13:23:52 | mriedem | it seems redundant t ome | |
| 13:24:10 | Kevin_Zheng | Hmm | |
| 13:24:32 | Kevin_Zheng | So you prefer not adding it | |
| 13:25:26 | sdague | mriedem: done | |
| 13:25:26 | Kevin_Zheng | And perhaps apps should rely on vm state instead of status | |
| 13:25:27 | Kevin_Zheng | ? | |
| 13:27:06 | mriedem | Kevin_Zheng: i don't have a strong feeling either way, we could add status to the InstancePayload if we wanted, i'd ask gibi too | |
| 13:27:11 | mriedem | but this is why we have versioned notifications now | |
| 13:27:14 | mriedem | so we can change them | |
| 13:27:50 | mriedem | Kevin_Zheng: i would like some more details on the use case, but that could come in a change or ML thread or something else | |
| 13:28:00 | mriedem | sdague: thanks | |
| 13:28:07 | Kevin_Zheng | yeah, I just find it might be useful as we already support filter by it | |
| 13:28:40 | sdague | mriedem: is there a current bug leader? | |
| 13:29:10 | sdague | mriedem: I was staring at the bugs again today and thinking about the way tags get "abused" in github for workflow | |
| 13:29:10 | stvnoyes | good morning mriedem. I have the cinder v3 migrate rv ready to go. I've been testing it with jgriffith 's POC changes and can migrate back and forth OK with a bfv instance and instances with attached volumes . I would appreciate your feedback on the changes. thanks. https://review.openstack.org/#/c/463987/ | |
| 13:29:19 | sdague | and think we could use some of that | |
| 13:29:30 | mriedem | sdague: there is no bug master | |
| 13:29:41 | mriedem | stvnoyes: ok | |
| 13:29:56 | mriedem | sdague: abused? | |
| 13:30:20 | sdague | mriedem: github has no real workflow states | |
| 13:30:25 | sdague | it's either open or clossed | |
| 13:30:50 | sdague | which means the entire incomplete / confirmed / triaged isn't used | |
| 13:30:55 | sdague | as it doesn't exist | |
| 13:31:12 | mriedem | oh right, i remember | |
| 13:31:13 | sdague | and instead projects use tags and bug bots to do workflow with tags | |
| 13:31:15 | mriedem | with GHE | |
| 13:31:25 | mriedem | inprogress, blocked, etc | |
| 13:31:31 | sdague | which, is actually a lot more flexible in a lot of ways | |
| 13:31:41 | sdague | because you can customize workflow to your project | |
| 13:31:51 | pabardina | Hello, I would like to use the "nova trigger-crash-dump", but how can I validate if it works correctly ? The cli doesn't do anything (on mitaka) thanks | |
| 13:32:39 | sdague | I was thinking about things like "needs.sub-team-triage" "needs.os-info" "needs.version-info" | |
| 13:32:42 | mriedem | pabardina: here are the functional tests for trigger crash dump in mitaka if those help https://github.com/openstack/python-novaclient/blob/stable/mitaka/novaclient/tests/functional/v2/test_trigger_crash_dump.py | |
| 13:33:44 | sdague | launchpad doesn't let you have : in tags, but it does let you have "." | |
| 13:34:07 | sdague | a bunch of that could be automatically applied with some text processing | |
| 13:34:19 | mriedem | Kevin_Zheng: when you say filter by status, you mean this right? https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L188-L208 | |
| 13:34:30 | mriedem | we really filter by vm/task state | |
| 13:34:37 | mriedem | the status thing is just an alias for the API user | |
| 13:34:46 | sdague | because a lot bugs just end up with no logical next step | |
| 13:35:06 | Kevin_Zheng | hmm yes | |
| 13:35:38 | mriedem | sdague: automatically applied how? cron job that pulls the bug down and scans the text and applies a tag? | |
| 13:35:54 | mriedem | i'm not even sure if we're supposed to be actively moving to storyboard or not | |
| 13:35:57 | mriedem | i've avoided that conversation | |
| 13:36:09 | sdague | mriedem: yeh, there are mqtt events on bug changes, we don't have to cron it | |
| 13:36:23 | Kevin_Zheng | but for SL for example, if we want to support filter by status, we have to maintain the mapping like in Nova | |
| 13:36:46 | Kevin_Zheng | vm_state + task_state -> status | |
| 13:36:54 | mriedem | Kevin_Zheng: true; when you say support filter by status in searchlight (SL reminds me of softlayer), are you talking about something added to the searchlight REST API? | |
| 13:37:31 | mriedem | sdague: yeah good point | |
| 13:38:41 | efried | johnthetubaguy yt? | |
| 13:38:51 | Kevin_Zheng | no, they are just transforming user input query params to ElasticSearch Query, so if it has this field, it can search | |
| 13:40:18 | sdague | mriedem: anyway, I'm playing with some things to see what might be useful to make the bug backlog not too crazy | |
| 13:41:01 | Kevin_Zheng | it can also transforming status query to vm_state + task_state, but means maintain the mapping :) | |
| 13:41:44 | openstack | Launchpad bug 1697825 in OpenStack Compute (nova) "nova-compute can not regist resource_provider when nova-compute start before placement endpoint created" [Undecided,New] - Assigned to zhang zhenzhong (zzzhang0118) | |
| 13:41:44 | mriedem | edleafe: dansmith: semi interesting placement related bug https://bugs.launchpad.net/nova/+bug/1697825 | |
| 13:42:37 | mriedem | sdague: ok - honestly i'm happy with anyone that's just looking at bugs | |
| 13:42:39 | mriedem | so go nuts | |
| 13:43:25 | mriedem | Kevin_Zheng: why search SL by the status field then? why not just search by the vm_state field? | |
| 13:43:29 | mriedem | if that's all SL has? | |
| 13:43:55 | sdague | ok, so I'm going to poke around at a few things and try to write up some ideas to the mailing list when I have something more concrete | |
| 13:44:50 | efried | Can anyone tell me if (and if so, why) it's illegal for a member of a notification payload to be None? | |
| 13:45:14 | mriedem | gibi: ^ | |
| 13:45:28 | mriedem | efried: which member? | |
| 13:45:34 | efried | Hehe. gibi is the reason I'm asking. | |
| 13:45:42 | efried | Trying to get to the bottom of https://review.openstack.org/#/c/455778/3/nova/notifications/base.py@394 | |
| 13:45:56 | openstackgerrit | Alex Xu proposed openstack/nova master: [placement] Update placement devref to modern features https://review.openstack.org/469047 | |
| 13:46:30 | dansmith | mriedem: we know about that one right? | |
| 13:46:46 | Kevin_Zheng | mriedem: just saying, nova currently support it :) | |
| 13:46:49 | dansmith | mriedem: tripleo was doing that, and we said starting compute before your catalog was setup was not a thing | |
| 13:47:13 | mriedem | Kevin_Zheng: sure, but i don't see that as a need for SL to need the same information | |
| 13:47:16 | mriedem | when it has the vm_state | |
| 13:47:19 | mriedem | which is essentially the same | |
| 13:47:36 | mriedem | dansmith: forgot about the tripleo case | |
| 13:47:41 | Kevin_Zheng | got it | |
| 13:48:25 | mriedem | Kevin_Zheng: again i'm not blocking it, i would just like a better idea of the end use case and flow, and requirements - which seem pretty thin if it's just "nova rest api has this field so SL should too" | |
| 13:48:37 | mriedem | but, we're doing that for other things | |
| 13:48:48 | Kevin_Zheng | yeah, I understand | |
| 13:48:52 | mriedem | https://blueprints.launchpad.net/nova/+spec/additional-notification-fields-for-searchlight i mean | |
| 13:49:39 | mriedem | efried: so setting https://github.com/openstack/nova/blob/9dde4fe0eacc01c135401da3313c493caa99a30c/nova/notifications/base.py#L478 to None makes legacy notifications blow up? | |
| 13:50:16 | efried | mriedem I think that's what we don't know. | |
| 13:50:29 | mriedem | because for a versioned payload that should be fine https://github.com/openstack/nova/blob/9dde4fe0eacc01c135401da3313c493caa99a30c/nova/notifications/objects/instance.py#L86 | |
| 13:50:34 | mriedem | since it's nullable=True | |
| 13:51:11 | efried | mriedem Right, although the only other place I can see that field being used, it's being defaulted to 0 | |
| 13:51:24 | efried | https://github.com/openstack/nova/blob/9dde4fe0eacc01c135401da3313c493caa99a30c/nova/api/openstack/compute/views/servers.py#L153 | |
| 13:53:42 | efried | What's a "legacy notification"? Or any notification, for that matter? Is it a way for an API consumer to register a kind of callback to return instance info periodically or when something happens? | |
| 13:54:28 | efried | (jaypipes FYI, trying to get to the bottom of https://review.openstack.org/#/c/455778/3/nova/notifications/base.py@394) | |
| 13:55:34 | jaypipes | efried: a legacy notification is any notification that doesn't use versioning | |
| 13:56:10 | efried | jaypipes Is there some reason a piece of the notification payload can't be None? | |
| 13:56:13 | jaypipes | efried: notification messages are sent out on the notifications topic queue and subscribers to that queue can take whatever action they want depending on the event type and payload | |
| 13:56:34 | jaypipes | efried: I don't believe so, which is the reason for my comment there :) | |
| 13:58:17 | openstackgerrit | Ed Leafe proposed openstack/nova master: Extract custom resource classes from flavors https://review.openstack.org/473627 | |