| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-19 | |||
| 13:11:30 | tssurya | mriedem, efried: targeting specific hosts | |
| 13:11:39 | mriedem | https://review.openstack.org/#/c/576693/ | |
| 13:11:45 | mriedem | needs +W | |
| 13:11:48 | mriedem | that's not rebuild though | |
| 13:12:17 | tssurya | rebuild is reschedule right ? for new images ? | |
| 13:12:27 | mriedem | yes, then you're looking for https://review.openstack.org/#/q/Ie252271ecfd38a0a1c61c26e323cc03869889f0a | |
| 13:12:30 | efried | tssurya: This one is related (though not quite a match) https://bugs.launchpad.net/nova/+bug/1777591 | |
| 13:12:31 | openstack | Launchpad bug 1777591 in OpenStack Compute (nova) "‘limit’ in allocation_candidates where sometimes make force_hosts invalid" [High,In progress] - Assigned to xulei (605423512-j) | |
| 13:12:34 | sean-k-mooney | tssurya: i did not think we allowed you to target a specific host with rebild. we dont allow you to bypass the scudler in anycase even if we do | |
| 13:12:43 | mriedem | sean-k-mooney: we don't, | |
| 13:12:48 | mriedem | but we run through the scheduler to validate the new image | |
| 13:12:56 | mriedem | on the existing instance.host | |
| 13:12:56 | tssurya | ah thanks, looks like that is what I am looking for, | |
| 13:13:07 | efried | oh, I didn't realize we had a fix up for that bug mriedem, looking now... | |
| 13:13:38 | sean-k-mooney | mriedem: in case i request something in the extraspecs that would make it invalid for that host im guessing | |
| 13:13:54 | mriedem | s/extraspec/image properties/ yes | |
| 13:14:06 | tssurya | we keep hitting https://github.com/openstack/nova/blob/f7e6d721f586ecbfee08c621f9e10174a4c6b35d/nova/scheduler/host_manager.py#L521 for new images | |
| 13:14:06 | mriedem | could be a windows image and you're on a linux host | |
| 13:14:12 | mriedem | well, not really that, but you get the idea | |
| 13:14:20 | mriedem | or something that violates aggregates | |
| 13:14:21 | sean-k-mooney | mriedem: ya | |
| 13:14:40 | mriedem | tssurya: that's not rebuild then... | |
| 13:14:44 | mriedem | you can't force_hosts/force_nodes on rebuild | |
| 13:14:59 | mriedem | unless it's coming out of the request spec | |
| 13:15:04 | mriedem | from when the instance was originally built | |
| 13:16:01 | sean-k-mooney | mriedem: for that to happen you would have first had to force the host on inital boot though right? | |
| 13:16:02 | mriedem | we don't call placement on rebuild | |
| 13:16:37 | tssurya | mriedem: we don't ? | |
| 13:16:44 | mriedem | no, see https://review.openstack.org/#/c/546357/5/nova/scheduler/manager.py | |
| 13:17:10 | mriedem | for a rebuild, quantitative aspects like the flavor aren't changing, | |
| 13:17:20 | mriedem | so we run qualitative filters and things that depend on the image | |
| 13:17:56 | tssurya | hmm, checking prod code to see if this change is there | |
| 13:18:04 | mriedem | i guess the api does set force_hosts during rebuild if you're rebuilding with a new image, | |
| 13:18:16 | mriedem | that's what tells the scheduler to run the filters on that exact host that the instance is already running on | |
| 13:19:14 | tssurya | awesome the above fix is not there in our queens | |
| 13:19:26 | mriedem | i thought you guys pulled from stable? | |
| 13:19:29 | tssurya | that's why rebuild is still going to placement | |
| 13:19:52 | tssurya | mriedem: we do, but we have some version stuff and backports from rocky which we should not have | |
| 13:19:58 | tssurya | and then it gets tricky | |
| 13:20:06 | mriedem | ack | |
| 13:20:12 | mriedem | well problem solved :) | |
| 13:20:19 | tssurya | (for instance dansmith's placement-request filter) | |
| 13:20:24 | tssurya | yea, thanks a ton! | |
| 13:21:17 | efried | mriedem: I'm fixing my nits | |
| 13:22:02 | openstackgerrit | Eric Fried proposed openstack/nova master: Disable limits if force_hosts or force_nodes is set https://review.openstack.org/576693 | |
| 13:22:06 | efried | mriedem: ^ | |
| 13:24:08 | mriedem | sean-k-mooney: your os-vif release doesn't seem like it needs to be a minor bump | |
| 13:24:12 | mriedem | it's mostly test and docs changes | |
| 13:25:11 | sean-k-mooney | i could make it 1.10.1 but made it 1.11.0 because i adde the noop plugin that said its a noop plugin... | |
| 13:25:41 | mriedem | yeah i noted that, | |
| 13:25:49 | mriedem | i guess there is more to that than what i first saw in the commit log | |
| 13:26:15 | sean-k-mooney | do you want me to make it 1.10.1 instead? | |
| 13:26:21 | mriedem | no i just +1ed | |
| 13:27:12 | sean-k-mooney | mriok cool. well the real reason for the noop plugin is to unblock https://review.openstack.org/#/c/565471/ | |
| 13:28:10 | mriedem | efried: isn't https://review.openstack.org/#/c/576693/7..8/nova/tests/unit/scheduler/test_utils.py needed for the assertResourceRequestsEqual call? | |
| 13:28:13 | sean-k-mooney | mriedem: ^ that was ment for you | |
| 13:28:47 | mriedem | oh i guess probably not, | |
| 13:28:58 | mriedem | assertResourceRequestsEqual is about comparing the request to the flavor right? | |
| 13:29:09 | mriedem | i thought it was weird that they had to set expected.is_limit | |
| 13:29:14 | mriedem | sean-k-mooney: yeah | |
| 13:29:54 | sean-k-mooney | im not sure we would want to depend on a z stream release to delete that code | |
| 13:30:15 | mriedem | sean-k-mooney: it's likely not going to happen in stein anyway - that removal from nova | |
| 13:30:19 | mriedem | *rocky | |
| 13:31:16 | sean-k-mooney | oh ok well in either case its not blocked anymore so it can be done when it makes sense | |
| 13:34:09 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Implement migrate_instance_start method for neutron https://review.openstack.org/556334 | |
| 13:34:10 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add VIFMigrateData object for live migration https://review.openstack.org/515423 | |
| 13:34:11 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add VIFMigrateData.get_dest_vif https://review.openstack.org/566931 | |
| 13:34:12 | openstackgerrit | Matt Riedemann proposed openstack/nova master: libvirt: factor out pre_live_migration plug_vifs call https://review.openstack.org/566932 | |
| 13:34:13 | openstackgerrit | Matt Riedemann proposed openstack/nova master: libvirt: use dest host port bindings during pre_live_migration https://review.openstack.org/566933 | |
| 13:34:14 | openstackgerrit | Matt Riedemann proposed openstack/nova master: libvirt: use dest host vif migrate details for live migration https://review.openstack.org/551370 | |
| 13:34:15 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Annotate flows and handle PortBindingDeletionFailed in ComputeManager https://review.openstack.org/551371 | |
| 13:34:16 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Port binding based on events during live migration https://review.openstack.org/434870 | |
| 13:34:17 | openstackgerrit | Matt Riedemann proposed openstack/nova master: conductor: use port binding extended API in during live migrate https://review.openstack.org/522537 | |
| 13:57:41 | efried | mriedem: I noodled with it a bit and came up with something that I think is a little cleaner and more explicit. | |
| 13:57:58 | openstackgerrit | Eric Fried proposed openstack/nova master: Disable limits if force_hosts or force_nodes is set https://review.openstack.org/576693 | |
| 13:57:59 | efried | mriedem: ^ | |
| 13:58:04 | efried | aaaand I'll stop voting on it. | |
| 13:59:58 | mriedem | efried: so i guess it was needed for assertResourceRequestsEqual yeah? | |
| 14:04:59 | efried | mriedem: No, it wasn't before, but it is now. | |
| 14:05:09 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Disable limits if force_hosts or force_nodes is set https://review.openstack.org/576693 | |
| 14:05:12 | alex_xu | mriedem: efried this patch sounds pretty close https://review.openstack.org/#/c/560317/24, appreciate you can help on it | |
| 14:05:18 | mriedem | yeah i looked at assertResourceRequestsEqual and see it's checking _limit | |
| 14:06:53 | efried | mriedem: But it wasn't checking is_limit/_limit_candidates | |
| 14:07:05 | mriedem | efried: yup i noticed later | |
| 14:07:07 | mriedem | +2 | |
| 14:07:07 | efried | mriedem: We good with this now? | |
| 14:07:21 | mriedem | alex_xu: yup i'd also like kashyap to be ok with the extra cpu mode flags | |
| 14:07:24 | efried | mriedem: Should I approve it or hold off since I mucked with it significantly? | |
| 14:07:45 | mriedem | alex_xu: hmm, has anyone looked into the powerkvm ci result failures on that? | |
| 14:08:28 | mriedem | Jul 19 11:35:55.551312 devstack-xenial-ppc64-284262 nova-compute[24588]: ERROR nova.compute.manager libvirtError: internal error: Unknown CPU model ppc64le | |
| 14:08:51 | mriedem | mmedvede: ^ | |
| 14:09:26 | kashyap | mriedem: Is there a full log for it? | |
| 14:09:32 | mriedem | https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/17/560317/24/check/tempest-dsvm-full-xenial/a80ccf4/screen-n-cpu.txt.gz | |
| 14:09:44 | kashyap | That's fast; thanks | |
| 14:19:53 | kashyap | mriedem: Two things seem very off there: | |
| 14:20:20 | kashyap | First, the binary name is: 'qemu-system-ppc64' not: 'qemu-system-ppc64le' for both 'ppc64' and 'ppc64le'. | |
| 14:20:46 | kashyap | Second, talking to a colleague who does PPC stuff, he says: | |
| 14:20:52 | kashyap | For Power8 guests, <cpu mode='host-model'><model>power8</model></cpu>; for Power9 guests, s/8/9/. | |
| 14:21:06 | kashyap | So the CPU model 'ppc64le' doesn't make sense at all. | |
| 14:21:35 | mriedem | that's not the model in this config | |