| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-17 | |||
| 16:53:17 | openstack | bug 1721652 in OpenStack Compute (nova) "Evacuate cleanup fails at _delete_allocation_for_moved_instance" [High,In progress] https://launchpad.net/bugs/1721652 - Assigned to Balazs Gibizer (balazs-gibizer) | |
| 16:53:41 | sean-k-mooney | before ovs offload we could have used the vnic type to differenciate sriov and ovs/linuxbirdge/vpp... but now we cant since vnic type direct is valid for both | |
| 16:53:59 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: fix cleaning up evacuated instances https://review.openstack.org/512716 | |
| 16:54:29 | gibi | mriedem, bauzas: sorry I was away from the computer. I can do the suggested refactor of https://review.openstack.org/#/c/510938/ in a follow up | |
| 16:58:13 | sean-k-mooney | mriedem: anyway thanks for reviewing it. one spec that is hopefully less contoversial since it was approved last cycle is https://review.openstack.org/#/c/504895/ i think all the code for that has been up for a few months also | |
| 17:00:10 | sean-k-mooney | mriedem: johnthetubaguy oh by the way was this https://review.openstack.org/#/c/499777/5 the cinder attach work you were suggesting emultating for the multiple port binding in relation to how upgrades should work | |
| 17:00:27 | mriedem | sean-k-mooney: no | |
| 17:00:35 | mriedem | sec | |
| 17:00:47 | mriedem | sean-k-mooney: https://specs.openstack.org/openstack/nova-specs/specs/queens/approved/cinder-new-attach-apis.html | |
| 17:01:39 | sean-k-mooney | mriedem: ah ok i have basically added johnthetubaguy suggestions to the latest version but ill go read that now | |
| 17:01:42 | sean-k-mooney | mriedem: thanks | |
| 17:02:14 | mriedem | i need to read the updates on the portbinding spec too | |
| 17:02:39 | edleafe | dansmith: Here's the scenario: cell conductor gets a list of alternates after the initial build attempt fails. Assume that all of these alternates are stale, and no longer have enough resources. Should the cell conductor just log it and do nothing, or should it raise an exception? | |
| 17:02:44 | edleafe | And if an exception, what kind? | |
| 17:03:09 | mriedem | NoValidHost? | |
| 17:03:27 | mriedem | cell conductor raising NoValidHost is something that can already happen today when you run out of alternatives | |
| 17:03:30 | mriedem | it will log a fault | |
| 17:03:33 | mriedem | instance goes to ERROR state | |
| 17:03:34 | mriedem | easy peasy | |
| 17:03:49 | dansmith | edleafe: it should do whatever would happen if we had no retries left in the current path | |
| 17:03:50 | dansmith | yeah | |
| 17:03:51 | dansmith | that | |
| 17:03:58 | edleafe | mriedem: that was my assumption, but I wanted to be sure there wasn't some other action | |
| 17:04:07 | openstackgerrit | Jan Zerebecki proposed openstack/nova master: Fix wording of debug message for future releases https://review.openstack.org/508261 | |
| 17:04:31 | edleafe | ah, so that should be the same as what happens in compute when there are no retries left. | |
| 17:04:37 | dansmith | right | |
| 17:08:59 | openstackgerrit | Elod Illes proposed openstack/nova master: WIP: Transform scheduler.select_destinations notification https://review.openstack.org/508506 | |
| 17:12:35 | dansmith | edleafe: so, looking at your third patch, | |
| 17:12:43 | dansmith | edleafe: we have limits in the reqspec, | |
| 17:13:03 | dansmith | oh, | |
| 17:13:22 | dansmith | the selection limits are really just for the return value from the rpc call to continue to include them is that right? | |
| 17:13:35 | dansmith | I was thinking we had to have them for communicating to the compute, but that is in reqspec | |
| 17:13:37 | dansmith | is that right? | |
| 17:13:57 | edleafe | dansmith: the caching scheduler needs them | |
| 17:14:16 | dansmith | the caching scheduler _sets_ them | |
| 17:14:22 | dansmith | the compute _needs_ them | |
| 17:14:44 | edleafe | ok, I thought it was needed in the filters | |
| 17:15:02 | dansmith | my point is, we really just need them in Selection so that the return from select_destinations(), which is now a bunch of Selections, can include the limits back to conductor, | |
| 17:15:06 | edleafe | but yeah, the compute will need them too | |
| 17:15:11 | dansmith | which will populate the reqspec | |
| 17:15:22 | dansmith | the filters don't need them, the filters are what put things into limits | |
| 17:15:42 | edleafe | ok, I guess I misunderstood mriedem's concerns | |
| 17:15:49 | dansmith | compute can get them from the reqspec | |
| 17:18:44 | mriedem | the limits are stored in the reqspec? | |
| 17:19:01 | mriedem | tbc, we pass a reqspec down to build_and_run_instance in compute and it's *totally* ignored | |
| 17:19:05 | mriedem | we pass the limits dict separately | |
| 17:19:57 | mriedem | ok i see the SchedulerLimits field in the request spec | |
| 17:20:02 | mriedem | i just don't think compute is using that today | |
| 17:20:14 | dansmith | mriedem: right, so this will be passing limits N more times than we currently pass it | |
| 17:20:39 | dansmith | I'm thinking maybe we just have select_destinations return (reqspec, alternates) with reqspec updated with limits, | |
| 17:20:53 | dansmith | and then we can avoid putting them into the selection | |
| 17:21:10 | dansmith | aside from numa, they'll be the same for num_instances, right? | |
| 17:21:14 | mriedem | need to see what actually populates RequestSpec.limits today | |
| 17:21:26 | dansmith | I think it's populate_filter_properties | |
| 17:23:48 | dansmith | https://github.com/openstack/nova/blob/master/nova/scheduler/utils.py#L367 | |
| 17:24:01 | mriedem | yeah looking at what calls that | |
| 17:24:12 | dansmith | conductor | |
| 17:24:39 | dansmith | https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L1110-L1110 | |
| 17:25:03 | mriedem | god what a weird mess | |
| 17:25:11 | dansmith | yeah | |
| 17:25:32 | dansmith | it's also still in the half-uncleaned-up reqspec object | |
| 17:25:42 | dansmith | the only problem is, | |
| 17:25:49 | dansmith | I think numa limits will be per-host, | |
| 17:25:58 | dansmith | although,hmm | |
| 17:26:08 | dansmith | maybe the regular limits won't because of the allocation ratios or something? | |
| 17:26:49 | dansmith | yeah, toast | |
| 17:26:50 | mriedem | we also aren't doing this trick for evacuate | |
| 17:26:51 | dansmith | gdi | |
| 17:27:30 | mriedem | not really sure why we have RequestSpec.limits at all since it's not used anywhere, i guess because RequestSpec was supposed to replace filter_properties | |
| 17:27:48 | dansmith | the thing that goes into limits for things like ramfilter varies per host | |
| 17:27:49 | dansmith | mriedem: yeah, all that is unfinished | |
| 17:28:04 | dansmith | mriedem: so we pass it in reqspec, and as an arg, and now in N alternates | |
| 17:28:21 | dansmith | oh and we pass filter_properties too | |
| 17:28:36 | dansmith | so reqspec, filter_properties, limits, and N*selection | |
| 17:28:36 | mriedem | to build_and_run_instance | |
| 17:28:37 | mriedem | yeah heh | |
| 17:28:46 | dansmith | I wonder if that's enough redundancy | |
| 17:28:58 | mriedem | RAID-4? | |
| 17:29:03 | mriedem | for limits | |
| 17:29:07 | dansmith | this is like raid 50 | |
| 17:29:45 | mriedem | ok yeah so the allocation ratios are per host, | |
| 17:29:49 | mriedem | so the limits are per host | |
| 17:29:55 | mriedem | so they go into the selection object yeah? | |
| 17:30:03 | dansmith | yeah, have to | |
| 17:30:15 | mriedem | and RequestSpec.limits is i guess just the same as the first host chosen | |
| 17:30:38 | dansmith | and filter properties | |
| 17:30:40 | dansmith | and limits | |
| 17:33:00 | mriedem | maybe this is an appropriate time to drop this in here https://review.openstack.org/#/c/499799/ | |
| 17:33:41 | mriedem | removes 5% of the request spec TODOs | |
| 17:43:35 | openstackgerrit | Jackie Truong proposed openstack/nova master: Implement certificate_utils https://review.openstack.org/479949 | |
| 17:46:16 | openstackgerrit | Eric Fried proposed openstack/nova master: Send Allocations to spawn https://review.openstack.org/511879 | |
| 17:46:27 | efried | dansmith gibi I think I hit your concerns ^ | |
| 17:59:30 | openstackgerrit | Jackie Truong proposed openstack/python-novaclient master: Microversion 2.54 - Add trusted_image_certificates https://review.openstack.org/500396 | |
| 18:08:16 | openstackgerrit | Merged openstack/nova master: fix cleaning up evacuated instances https://review.openstack.org/510938 | |
| 18:09:58 | dansmith | efried: sorry if I wasn't clear, but I don't think adding a whole new fixture just to mock that one thing makes sense, | |
| 18:10:12 | dansmith | I just wanted you to use MonkeyPatch in there instead of mock.start() and addCleanup() | |
| 18:11:17 | dansmith | efried: like this for example: https://github.com/openstack/nova/blob/master/nova/tests/unit/virt/test_virt_drivers.py#L96 | |
| 18:22:36 | gregwork | is there a way to pass custom options to qemu via nova ? | |
| 18:22:48 | gregwork | such that when a guest starts up it starts with those extra options | |
| 18:28:17 | artom | gregwork, like literally custom qemu command line options? No. | |