| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-06 | |||
| 14:03:53 | mriedem | otherwise i shall take it to the ML | |
| 14:03:57 | dansmith | mriedem: okay | |
| 14:04:08 | stephenfin | cdent: You should hire Liz Lemon - she's much better than me at this stuff https://www.youtube.com/watch?v=aocZo3oeNxw | |
| 14:04:39 | mriedem | dansmith: the extend volume change in nova - https://review.openstack.org/#/c/454322/ - i started writing a tempest test for that yesterday, since there is also a cinder change, | |
| 14:04:53 | mriedem | the user (non-admin) can extend their volume in cinder, so like 1G->2G, | |
| 14:04:59 | cdent | stephenfin: she's probably busy | |
| 14:05:07 | mriedem | cinder will call the os-server-external-events API telling nova the volume attached to a server was resized, | |
| 14:05:21 | mriedem | we send that down to the compute to fiddle the os-brick bits (i'm channeling johnthetubaguy-speak here) | |
| 14:05:31 | mriedem | "fiddling bits" is a british term right? | |
| 14:05:47 | dansmith | mriedem: I believe it is yes | |
| 14:05:54 | mriedem | so i asked that an instance action get tracked on the nova side since this is all async, | |
| 14:05:57 | mriedem | that's done, all well and good, | |
| 14:06:00 | edleafe | stephenfin: I settled on 'edleafe' long ago for all my accounts. Not enough brain cells to keep track of different handles | |
| 14:06:12 | mriedem | problem comes in on the api user side trying to sort out when the actual operation is done on the nova side, | |
| 14:06:18 | edleafe | stephenfin: plus all the branding synergy, of course | |
| 14:06:29 | mriedem | i was relying on the instance action events in tempest - however, the events are only shown for admin users | |
| 14:06:30 | stephenfin | edleafe: Yup, my problem exactly. Plus it helps with branding | |
| 14:06:32 | stephenfin | jinx :) | |
| 14:06:43 | edleafe | :) | |
| 14:06:47 | mriedem | so we can get tempest to work since we have admin and non-admin creds, but that's a hack, | |
| 14:06:57 | mriedem | so i was thinking, we should probably set a task_state on the instance in this case, | |
| 14:07:05 | dansmith | mriedem: UGH | |
| 14:07:09 | mriedem | so the api user can poll the task state change to know when the nova side is done | |
| 14:07:11 | mriedem | i know | |
| 14:07:27 | dansmith | mriedem: that's not really what task_state is for, IMHO, so it would be a bad choice | |
| 14:07:47 | mriedem | well, unless there is something else, it's task_state or instance actions, | |
| 14:07:47 | dansmith | that and it will lock us from doing anything like a shutdown or something if that gets hung | |
| 14:07:48 | dansmith | which is fairly icky | |
| 14:07:52 | mriedem | and as noted, the action events are admin-only | |
| 14:07:59 | mriedem | well, | |
| 14:08:01 | dansmith | well, vm_state has fewer issues with that, | |
| 14:08:08 | dansmith | but I'm loathe to alter any of them really | |
| 14:08:13 | mriedem | i considered that an upside - that someone can't stop your instance while it's having the volume extended | |
| 14:08:26 | mriedem | but, | |
| 14:08:35 | dansmith | so they can see the action but not the events? | |
| 14:08:41 | mriedem | we also can't accept the call from cinder if the task_state is already set either, b/c we'd get UnexpectedTaskStateERror | |
| 14:08:45 | mriedem | dansmith: correct | |
| 14:09:02 | mriedem | https://review.openstack.org/#/c/480792/ | |
| 14:09:03 | dansmith | mriedem: does the action get the finish_time set when it's done? | |
| 14:09:07 | mriedem | nope | |
| 14:09:09 | mriedem | that's on the event | |
| 14:09:19 | dansmith | mriedem: not according to the object model | |
| 14:09:21 | sean-k-mooney | stephenfin: os_vif.objects.network.Network is used to pass info the os-vif plugins about the network such as mtu, it is created from nova.network.model.Network. nova.network.model.Network is used to pass network related info that will be needed to influenc the libvirt xml generation. you only need to modify nova.network.model.Network so that you can populate the metatda for cloud init | |
| 14:09:47 | dansmith | mriedem: https://github.com/openstack/nova/blob/master/nova/objects/instance_action.py#L39-L39 | |
| 14:10:28 | mriedem | hmm, i don't know if anything calls action_finish or finish, | |
| 14:10:29 | mriedem | looking | |
| 14:11:00 | mriedem | i know we don't expose finish_time in the api for the action https://developer.openstack.org/api-ref/compute/?expanded=list-actions-for-server-detail#servers-actions-servers-os-instance-actions | |
| 14:11:03 | mriedem | only the events | |
| 14:11:07 | mriedem | but that could easily be changed | |
| 14:11:09 | dansmith | heh | |
| 14:11:15 | sean-k-mooney | stephenfin: we basicaly need to create os_vif.objects.network.Network so that there would not be a circular dependency between os-vif and nova. | |
| 14:11:34 | stvnoyes1 | good morning mriedem: I updated the live migrate review, addressing your comments. Please take a look when you get a chance. Thanks. - https://review.openstack.org/#/c/463987/ | |
| 14:11:47 | dansmith | mriedem: I wonder why that is, but it seems like that'd be a thing you look for if you're using the action to identify the long-running thing | |
| 14:12:43 | mriedem | dansmith: yeah so nothing calls InstanceAction.action_finish / finish today | |
| 14:12:54 | mriedem | so we have the finish-time field in the data model, but nothing sets it | |
| 14:13:02 | mriedem | stvnoyes1: ok | |
| 14:13:04 | dansmith | hrm, that seems weird | |
| 14:13:14 | dansmith | and unfortunate | |
| 14:13:47 | mriedem | i think i asked alaski about this a long time ago, | |
| 14:13:52 | mriedem | and the tasks api came up | |
| 14:14:00 | dansmith | mriedem: so, exposing events is one way I guess, as long as you filter out traceback for the non-admins, but that's a whole thing | |
| 14:14:02 | mriedem | and then a black hole opened somewhere | |
| 14:14:04 | dansmith | hehe | |
| 14:14:16 | mriedem | dansmith: right, that's another option, | |
| 14:14:23 | mriedem | expose events but filter the traceback like we do for instance fault | |
| 14:14:24 | dansmith | I really think using one of the states to handle this is just asking for trouble, but ... | |
| 14:14:28 | dansmith | yeah | |
| 14:14:36 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add sample test for instance audit https://review.openstack.org/480955 | |
| 14:14:47 | mriedem | i would prefer not to complicate this with a new task_state | |
| 14:14:54 | mriedem | because at that point, | |
| 14:15:04 | mriedem | using the os-server-external-events api for this is really overloading it's function | |
| 14:15:27 | dansmith | my concern with a new state is destabilizing everything else with a new task state, which doesn't expose itself until it's out in the wild and someone finds a dead end in the "state machine" | |
| 14:15:57 | mriedem | yeah so to recap options, | |
| 14:16:17 | mriedem | 1. do nothing - end user can see the action show up for the instance but after that, shrug - maybe they can check something by ssh'ing into the guest, idk, | |
| 14:16:40 | mriedem | 2. start setting the finish_time on the action record and expose that out of the instance actions api (in the same microversion i suppose) | |
| 14:16:56 | mriedem | 3. expose the events but hide the traceback for non-admins by default (in a microversion) | |
| 14:17:21 | dansmith | 4. break the "state machine" | |
| 14:17:31 | mriedem | i was intentionally excluding that one | |
| 14:17:34 | dansmith | ack | |
| 14:18:04 | mriedem | #3 is probably the easiest | |
| 14:18:22 | mriedem | #2 would be new plumbing since we haven't ever "finished" an action record before, | |
| 14:18:29 | mriedem | so i don't know what dragons are there | |
| 14:18:44 | dansmith | might also be confusing because people will see all their actions suddenly look unfinished | |
| 14:18:49 | dansmith | like, years-old actions if they're still there | |
| 14:18:56 | mriedem | yeah, | |
| 14:18:57 | mriedem | on that note, | |
| 14:18:59 | dansmith | we couldfix that, but we'd need to finish all our actions everywhere going forward | |
| 14:19:13 | mriedem | my musing last night led to something like, consider the action finished if it had at least one event and all events had a finish_time set, | |
| 14:19:19 | mriedem | but there is a window where that could be wrong | |
| 14:19:34 | dansmith | yeah, it would flap back and forth | |
| 14:19:41 | mriedem | assuming we have any actions with >1 event | |
| 14:19:47 | dansmith | because we don't declare all our events ahead of time | |
| 14:19:51 | dansmith | would be nice if we did, but.. | |
| 14:19:57 | mriedem | sure, that's tasks api | |
| 14:19:58 | mriedem | i guess | |
| 14:20:00 | dansmith | right | |
| 14:20:05 | mriedem | watch your footing | |
| 14:20:18 | dansmith | heh | |
| 14:20:35 | mriedem | so i'm thinking "expose the events but hide the traceback for non-admins by default (in a microversion)" is the winner | |
| 14:20:47 | dansmith | I guess so | |