| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-14 | |||
| 15:24:31 | lyarwood | a normal revert you mean, of the stable/queens patch | |
| 15:25:00 | dansmith | what I mean is, a backport of the revert patch from master and rocky might not be worth it, | |
| 15:25:23 | dansmith | but we could do a straight revert of the queens patch on queens yeah | |
| 15:25:24 | dansmith | lyarwood: do you know of any precedent for that? | |
| 15:25:32 | lyarwood | kk, in the past we've just done a straight revert of the stable changes, not backporting anything from branch to branch | |
| 15:25:46 | dansmith | really? | |
| 15:25:53 | prometheanfire | ya, that's kinda what I was thinking | |
| 15:26:03 | dansmith | I'm confident that we've backported reverts, and that's what mriedem did for stable/rocky | |
| 15:26:07 | prometheanfire | iirc, a clean revert isn't possible either for pike at least | |
| 15:26:14 | dansmith | but if that's kosher, that's likely way easier | |
| 15:26:27 | lyarwood | dansmith: I assume it was clean? | |
| 15:26:41 | dansmith | which? I haven't tried the direct revert yet | |
| 15:26:43 | lyarwood | dansmith: once things start to conflict the revert backports get awkward | |
| 15:26:51 | dansmith | yup | |
| 15:27:18 | lyarwood | dansmith: the master to rocky revert sorry, and I assume it was as rocky was only just cut | |
| 15:27:31 | dansmith | yeah, I assume it was, matt did it | |
| 15:28:10 | dansmith | lyarwood: so, different change-id for the revert on queens? or force it to be the same so gerrit shows it properly? | |
| 15:29:06 | lyarwood | dansmith: it has to be different doesn't it? | |
| 15:29:26 | dansmith | no, I can force it to be the same | |
| 15:29:35 | lyarwood | dansmith: I didn't think gerrit allowed the same change-id twice on the same branch | |
| 15:29:53 | dansmith | I mean the same change-id as the reverts on master and rocky | |
| 15:30:17 | dansmith | meaning, use that change id on queens too, even though it's not a direct cherry-pick | |
| 15:30:22 | lyarwood | dansmith: ah right, yeah the same change id for the reverts | |
| 15:30:33 | openstackgerrit | Dan Smith proposed openstack/nova stable/queens: Revert "libvirt: slow live-migration to ensure network is ready" https://review.openstack.org/591761 | |
| 15:30:37 | dansmith | okay, queens was clean ^ | |
| 15:31:58 | dansmith | as was pike | |
| 15:32:00 | openstackgerrit | Dan Smith proposed openstack/nova stable/pike: Revert "libvirt: slow live-migration to ensure network is ready" https://review.openstack.org/591762 | |
| 15:33:01 | prometheanfire | nice | |
| 15:35:46 | openstackgerrit | Eric Fried proposed openstack/nova master: [placement] split gigantor SQL query, add logging https://review.openstack.org/591510 | |
| 15:37:47 | openstackgerrit | Eric Fried proposed openstack/nova master: [placement] split gigantor SQL query, add logging https://review.openstack.org/590041 | |
| 15:45:11 | Sundar_ | efried: Please ping me when you have the time. Thanks. | |
| 15:51:52 | openstackgerrit | xhzhf proposed openstack/nova master: [vmware] add missing os types in vSphere sdk 6.5 https://review.openstack.org/591771 | |
| 15:54:17 | efried | Sundar_: Yo, what's up? | |
| 15:57:17 | Sundar_ | Hi efried, please look at my email to you on merge conflict. | |
| 15:57:43 | efried | Sundar_: Roger that, looking. | |
| 15:57:50 | efried | Sundar_: You probably just need to rebase to master. | |
| 15:58:22 | efried | Sundar_: Right, so I see you tried that, let me see what I can do. | |
| 16:02:49 | efried | Sundar_: What problem did you have rebasing this? It's working out okay for me. | |
| 16:05:10 | efried | Sundar_: Fixed, uploaded PS8 | |
| 16:11:15 | melwitt | . | |
| 16:14:59 | Sundar_ | Thanks, efried! I explained the problem in the email. | |
| 16:15:22 | efried | Sundar_: I responded to the email. Hopefully I understood the problem correctly. Let me know if PS8 looks correct. | |
| 16:16:03 | efried | Sundar_: Looks like you uploaded a no-op PS9 :) | |
| 16:16:15 | efried | (no op other than to change the committer back to yourself) | |
| 16:18:00 | Sundar_ | efried: Yes. I retried my steps to see where the issue is, and there were no issues. The 'git review' succeeded too. Not sure if the no-op patch is an issue. Should we revert that? | |
| 16:19:06 | sean-k-mooney | Sundar_: your noop patch just changed the commiter field in the reivew. it wont have any real effect | |
| 16:19:36 | efried | Sundar_: Right, leave it as is. | |
| 16:19:45 | openstackgerrit | Dan Smith proposed openstack/nova stable/queens: DNM: Debug patch to test live migration waiting https://review.openstack.org/591775 | |
| 16:20:41 | Sundar_ | sean-k-mooney, efried: Thanks. Hopefully I have included all previous input from both of you and others. But there were tons of them, so I will do another review myself. Please LMK if I missed anything. | |
| 16:20:51 | efried | ack | |
| 16:22:38 | sean-k-mooney | dansmith: regardin the live migration waiting is there any testing i can help with. im currently testing migraitng between different backend / configuration but i have that flag set also | |
| 16:23:03 | dansmith | sean-k-mooney: confirming the new thing works for LB would be great | |
| 16:23:29 | sean-k-mooney | dansmith: lb->lb seams to work fine on master | |
| 16:23:39 | sean-k-mooney | well master as of yesterday | |
| 16:23:39 | dansmith | as expected, cool | |
| 16:23:50 | sean-k-mooney | is there a partcalar patch i should check i have | |
| 16:25:07 | sean-k-mooney | i have the Merge "Revert "libvirt: slow live-migration to ensure network is ready"" patch | |
| 16:25:25 | dansmith | that | |
| 16:25:31 | dansmith | and did you turn on the manager waiter? | |
| 16:26:01 | dansmith | the thing I'm forcing to true in this test patch: https://review.openstack.org/591775 | |
| 16:26:03 | sean-k-mooney | live_migration_wait_for_vif_plug = True | |
| 16:26:12 | dansmith | yep | |
| 16:26:13 | dansmith | cool | |
| 16:26:23 | sean-k-mooney | in the compute section. ya i copied the stuff form the gate job | |
| 16:27:10 | dansmith | sweet | |
| 16:27:14 | dansmith | that's super helpful thanks :) | |
| 16:27:50 | kosamara | sean-k-mooney: I didn't get your affinity/anti-affinity comment. Affinity has meaning per physical device? | |
| 16:27:59 | sean-k-mooney | livemigration between ovs and linux bridge is not workigk. looks like we missed a few thing on the neutron side. im goint to test live migration between host with and without iptable firewall driver next | |
| 16:29:08 | sean-k-mooney | kosamara: in the granualar resouce provider spec we expcitly say if different resouce request groups are allowed to come form teh same resouce provier or may not come form the same resource provider | |
| 16:29:30 | sean-k-mooney | kosamara: this is so we can model affinity or anti afinity for different usecases | |
| 16:30:28 | sean-k-mooney | kosamara: i dont think you have to worry about that in your spec. its more on the consumtion side then whitelisting | |
| 16:30:45 | kosamara | sean-k-mooney: right. The question is between modelling each physical device as an RP vs aggregating inventories with same traits into 1 RP. Does affinity affect this? | |
| 16:32:36 | sean-k-mooney | if each device is a seperate RP we can say i want 2 devices from teh same resouce provider. e.g. 2 dispaly heads from the same gpu | |
| 16:33:03 | sean-k-mooney | well you might be able to i would have to think about it. | |
| 16:34:24 | openstackgerrit | Eric Fried proposed openstack/nova master: Remove blacklisted py3 xen tests https://review.openstack.org/591419 | |
| 16:34:45 | kosamara | You have a good point there. Also, I don't know if anyone has a use for sound devices, but some GPUs provide 2 pci devices (functions), a VGA and a sound, that can't be given to separate VMs. | |
| 16:35:13 | kosamara | Also relevant for supporting NVlink, which appears as many individual pci devices | |
| 16:36:22 | sean-k-mooney | kosamara: ya i would hope this should effect how we model the config file but will effect how the device are consumed from placement. | |
| 16:37:13 | sean-k-mooney | i mean i could but i guess it comes down to how granular things are | |
| 16:39:05 | kosamara | sean-k-mooney for sure if there is a use case for requesting 2 display heads from the *same physical device*, aggregating would break it. | |
| 16:40:59 | sean-k-mooney | kosamara: you also have the inverse. i want to dispaly heads from different devices. which not aggregating make much more complicated :) | |
| 16:42:16 | sean-k-mooney | a better example of the anti afinity is sriov VF for nics. i want to ensure that they comre form 2 differnet phyical cards for HA | |
| 16:42:56 | kosamara | again aggregating would break this | |
| 16:46:03 | sean-k-mooney | not how aggreting is propsed to work the aggreation point for VFs is the PR so one RP per pf and each PF RP would have an inventory of VFs | |
| 16:46:28 | sean-k-mooney | /PR/PF/ | |
| 16:47:03 | mdbooth | melwitt: Incidentally, I'm not actually convinced that adding destroy_disks_on_failure to spawn is right either. We already have a functional entry point to the driver for this case: rebuild. | |
| 16:47:10 | kosamara | aggregating: I meant many PFs -> 1 RP | |
| 16:47:11 | mdbooth | melwitt: Still undecided. | |
| 16:48:23 | sean-k-mooney | kosamara: if the PF have no VF the you can safly aggreate them at the numa node level assume the PF are other wise identical | |
| 16:48:53 | sean-k-mooney | kosamara: anyway we dont need to cover all the edgecases on irc :) | |
| 16:49:30 | kosamara | sean-k-mooney: ok, etherpad :) | |
| 16:54:04 | melwitt | mdbooth: okay | |
| 16:57:41 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Consumer gen: remove_provider_from_instance_allocation https://review.openstack.org/591784 | |
| 17:02:29 | efried | jroll, jaypipes: Can this test be deleted at this point? https://github.com/openstack/nova/blob/61f854ff6445dd7bc797fdde7361e47f3dc3b1bd/nova/tests/functional/compute/test_resource_tracker.py#L215 | |
| 17:02:49 | mdbooth | melwitt: I'm not keen on anything involving task state, though: it's a wild west. It's basically impossible to verify, and almost guaranteed to suffer bitrot. | |
| 17:03:01 | jaypipes | efried: should be able to, yes. | |
| 17:03:08 | jaypipes | efried: double check with mriedem and dansmith | |
| 17:03:17 | efried | jaypipes: ight, will do so via review I guess. | |
| 17:03:20 | jroll | I thought we had a patch out to drop those things | |
| 17:03:33 | mdbooth | I think it's robust to verify task state set vs not set, anything else is asking for trouble. | |