| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-06 | |||
| 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 | |
| 14:20:52 | dansmith | I like #1, but... yeah :) | |
| 14:20:53 | mriedem | "winner" | |
| 14:21:01 | mriedem | do quotes help? | |
| 14:21:04 | dansmith | yeah, hard to feel like you won, when that's the solution | |
| 14:21:05 | dansmith | heh | |
| 14:21:41 | mriedem | i also don't feel like working this into the same microversion, since it will clutter up an already large change, | |
| 14:21:56 | mriedem | but also not sure i want to create a new separate microversion just for that | |
| 14:22:38 | mriedem | alright, anyway, this was helpful | |
| 14:22:41 | dansmith | yeah, I dunno.. would be nice to save a microversion, but reading the history, it'll be like "this volume thing and oh also we exposed this other random thing, kthxbai" | |
| 14:22:46 | sean-k-mooney | stephenfin: by the way if you have not seen https://review.openstack.org/#/c/390513/ and https://review.openstack.org/#/c/390512/ they are releated to the issue your trying to solve | |
| 14:23:27 | stephenfin | sean-k-mooney: I think I saw one but not the other. I'll take a look now :) | |
| 14:24:08 | stephenfin | sean-k-mooney: meanwhile, I _think_ this is correct, but I'm not sure if it's even necessary given your comments about not using a fqdn for hostname https://review.openstack.org/#/c/480676/ | |
| 14:24:15 | mriedem | dansmith: that's basically how the services/hypervisors uuid api changes read out in the rest api version history and release notes :) | |
| 14:24:22 | dansmith | mriedem: heh | |
| 14:24:26 | mriedem | "take and return uuid instead of id, plus a whole bunch of other shit" | |
| 14:24:27 | sean-k-mooney | stephenfin: the first one is proposing a single api endpoint to return all the info to populate the metadat. the second is the nova/neutont negociation sepc where i would like to use os vif as the serialisation format | |
| 14:24:45 | mriedem | 500 microversions also sucks | |
| 14:24:59 | dansmith | yeah | |
| 14:26:38 | sean-k-mooney | stephenfin: lookin at it now. did you add the dns_domain field in the previous patches | |
| 14:27:12 | stephenfin | sean-k-mooney: I don't think it's necessary - that model does weird stuff with a 'meta' field that's mostly autopopulated | |
| 14:27:22 | stephenfin | sean-k-mooney: Look at the patch that added 'mtu' support | |
| 14:30:01 | openstackgerrit | Stephen Finucane proposed openstack/nova master: libvirt: fix memory locking limit https://review.openstack.org/472633 | |
| 14:30:06 | jaypipes | dansmith, ildikov: :) | |
| 14:31:41 | mriedem | mgagne: fyi in case you haven't been following along https://review.openstack.org/#/c/454322/27/nova/compute/api.py | |
| 14:31:57 | mriedem | mgagne: let's talk about how you'd like to proceed - if you want me to work on the os-instance-actions api change in there | |
| 14:32:38 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add BDM to InstancePayload https://review.openstack.org/448779 | |
| 14:40:56 | foutatoro | hi all, I'm trying to create KVM instance with ubuntu cloud images used in Openstack with virt-install but I always get the error "No bootable device found". | |
| 14:41:06 | foutatoro | can someone help me to solve that please ? | |
| 14:42:15 | openstackgerrit | Merged openstack/os-vif master: Rehome unit tests to ``tests\unit`` folder https://review.openstack.org/476623 | |
| 14:42:27 | openstackgerrit | Merged openstack/os-vif master: Use ``assert_has_calls`` to check function calls https://review.openstack.org/477469 | |
| 14:57:08 | jaypipes | while `tox -epy27,pep8`; do process_emails.sh; done | |
| 14:58:10 | mriedem | ildikov: so the cinder v3 api changes are stacked such that swap volume should get tested in the top patch which does the new style attach, right? | |
| 14:58:50 | mriedem | ildikov: because there is a swap volume test in tempest, but i don't think it runs in the normal tempest dsvm jobs because it's marked as 'slow' | |
| 14:59:19 | ildikov | mriedem: it should run as it was failing until I added the swap patch in the chain | |
| 14:59:43 | mriedem | ok i'll take a look | |
| 15:00:33 | ildikov | mriedem: you can take a thorough look at both the dependencies and on the attach patch | |
| 15:00:43 | ildikov | just to keep everyone busy :) | |
| 15:06:59 | jaypipes | mriedem: ralonsoh is looking for this (yet unmerged) patch: https://review.openstack.org/#/c/466040/ | |
| 15:07:20 | jaypipes | mriedem: but you're right to say that 0.3.2 doesn't include that (since obvi it's not merged yet) | |
| 15:07:57 | jaypipes | I'm approving that now. it needed rebasing after the unit test re-org | |
| 15:07:59 | openstackgerrit | sahid proposed openstack/nova master: libvirt: fix memory locking limit https://review.openstack.org/472633 | |