Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-14
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.
17:03:47 melwitt mdbooth: yeah. that would only be for the sake of the backport. I agree it's not ideal, but the copying of code from manager to driver is more prone to bitrot IMHO
17:03:57 dansmith efried: I'm sure we can because we don't technically support that mix of versions anyway
17:04:11 mdbooth melwitt: Yeah. I also don't love that.
17:04:16 efried dansmith: ack, proposing...
17:04:43 mdbooth melwitt: I think the behaviour being tested by the regression test, namely relying on instance_on_disk() is ok.
17:05:12 mdbooth The principal being: if we created it, we should clean it up. If we didn't, we shouldn't.
17:05:34 openstackgerrit Eric Fried proposed openstack/nova master: Remove obsolete func test_ironic_ocata_to_pike https://review.openstack.org/591785
17:05:39 mdbooth I think that's moderately robust, although as noted in the comment I think we can also do better with a bit more work.
17:05:41 efried dansmith, jaypipes, jroll, mriedem: ^
17:07:23 jroll efried: thanks. you reminded me I need to pick this one back up too https://review.openstack.org/#/c/565841/
17:07:29 jaypipes efried: terrible code. -3.
17:07:33 sean-k-mooney mriedem: just an FYI livemigratin between an ovs host with ip tables firewall and openvswtich firewall and back appear to work correctly.
17:07:46 efried jroll: I was just looking at that a few minutes ago.
17:08:17 sean-k-mooney mriedem: im going to do a bit more testing but the xml is corerctly updated so i just going to check that the firewall actully works during the live migration
17:08:18 jroll heh
17:23:19 mdbooth dansmith melwitt: Rather than changing rebuild specifically, how about if I changed spawn() in the libvirt driver such that, unconditionally, it only deletes the instance directory if it created it, and it only deletes disks if it created them.
17:24:08 mdbooth spawn() is called by compute manager for: boot, unshelve, rebuild.
17:24:43 mdbooth For the first 2 nothing should exist already, but the current behaviour is to ignore that.
17:25:12 mdbooth So the only case where it might legitimately exist already is rebuild on shared storage.
17:37:04 sean-k-mooney mdbooth: for rebuild on shared stroage the disk might exists and the instance directory but we have to recreate teh disk from the new iamage anyway right
17:47:07 openstackgerrit Jim Rollenhagen proposed openstack/nova master: Ironic: report 0 for vcpus/memory_mb/disk_gb resources https://review.openstack.org/565841
17:47:18 jroll efried: I think that does it ^
17:48:32 melwitt mdbooth: my initial thought is, I'm not sure that sounds good for a backport, but rather a possible refactor. I'm not sure what all would be involved there or any gotchas
17:48:45 openstackgerrit Dan Smith proposed openstack/nova stable/queens: DNM: Debug patch to test live migration waiting https://review.openstack.org/591775
18:15:59 openstackgerrit Balazs Gibizer proposed openstack/nova master: Consumer gen support for put allocations https://review.openstack.org/591647
18:16:00 openstackgerrit Balazs Gibizer proposed openstack/nova master: Consumer gen: remove_provider_from_instance_allocation https://review.openstack.org/591784
18:16:01 openstackgerrit Balazs Gibizer proposed openstack/nova master: consumer gen: support claim_resources https://review.openstack.org/583667
18:16:02 openstackgerrit Balazs Gibizer proposed openstack/nova master: consumer gen: move_allocations https://review.openstack.org/591810
18:16:03 openstackgerrit Balazs Gibizer proposed openstack/nova master: consumer gen: more tests for delete allocation cases https://review.openstack.org/591811
18:19:13 openstackgerrit Merged openstack/nova stable/rocky: Revert "libvirt: slow live-migration to ensure network is ready" https://review.openstack.org/591275
18:36:25 efried jroll: Soft -1 on the reno (as well as pep8)
18:41:22 jroll ughhhhhhh
18:43:25 jroll thanks efried
18:44:06 openstackgerrit Jim Rollenhagen proposed openstack/nova master: Ironic: report 0 for vcpus/memory_mb/disk_gb resources https://review.openstack.org/565841
18:51:21 efried much clearer, thanks jroll
18:51:28 jroll :)
20:19:31 cfriesen maybe odd question, but if I boot an instance from a flavor with trait:HW_CPU_X86_AVX2=required, the exact CPU model chosen seems to depend on the nova-compute config. Suppose I then try to live-migrate...I'm guaranteed that the dest node will support AVX2, but Is there somewhere that we verify that the dest node can support the same CPU model as is currently being used by the running VM?
20:31:23 cfriesen never mind, found the code. the scheduler filters don't check, but check_can_live_migrate_destination() should catch it.
20:42:23 openstackgerrit Jay Pipes proposed openstack/nova master: DNM: test possible deadlock cause https://review.openstack.org/591845
21:15:52 openstackgerrit Chris Dent proposed openstack/nova master: Add explanatory prefix to post_test_perf output https://review.openstack.org/591850
21:19:32 openstackgerrit Chris Dent proposed openstack/nova master: DNM: test possible deadlock cause https://review.openstack.org/591845
21:21:10 efried cdent: Love it.

Earlier   Later