Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-14
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.
21:22:03 cdent I suppose once we've all memorized those words we can read right over them
21:25:11 efried cdent: One concern is tying that behavior to a specific version of placeload.
21:25:33 efried Perhaps a TODO to vet that periodically.
21:26:14 cdent but where will we put the todo to remind us to look for todos?
21:27:26 openstackgerrit Dmitry Sutyagin proposed openstack/nova master: Implement disabling KSM via flavor's extra specs https://review.openstack.org/591854
21:30:31 openstackgerrit Eric Fried proposed openstack/nova master: PowerVM: update_provider_tree() (compatible) https://review.openstack.org/468560
21:30:39 efried edmondsw, jaypipes: ^
21:32:15 openstackgerrit Jim Rollenhagen proposed openstack/nova master: Ironic: report 0 for vcpus/memory_mb/disk_gb resources https://review.openstack.org/565841
21:32:54 jroll efried: jaypipes: ^ had a syntax error in release note :(
21:33:11 efried jroll: Wish somebody had been paying attention to your release note
21:33:17 jroll heh
21:33:24 jroll I did your suggestion too :)
21:33:53 efried d'oh, I should have caught that.
21:33:55 efried thanks.
21:34:16 efried jroll: +A
21:35:05 jroll thanks
22:35:28 melwitt mriedem: fyi added a question to the RC todos etherpad about translations
22:40:11 openstackgerrit Eric Fried proposed openstack/nova master: [placement] Regex consts for placement schema https://review.openstack.org/591863
#openstack-nova - 2018-08-15
00:20:31 openstackgerrit xhzhf proposed openstack/nova master: [vmware] add missing os types in vSphere sdk 6.5 https://review.openstack.org/591771
00:29:55 mriedem melwitt: ack, just got online
00:35:16 mriedem dansmith: lyarwood: fwiw, i backported the live migration revert from master to stable/rocky b/c i was sure that would be clean since we just cut stable/rocky, but assumed we'd have to revert per-branch for queens and pike
00:39:03 mriedem efried: re: https://github.com/openstack/nova/blob/61f854ff6445dd7bc797fdde7361e47f3dc3b1bd/nova/tests/functional/compute/test_resource_tracker.py#L215 have we removed the compat code in the RT for that yet? or are you saying we can now because master is stein? i would hold off on merging any big code removals this early until we've cut rc2
00:43:39 openstackgerrit Matt Riedemann proposed openstack/nova stable/rocky: placement: ignore policy scope check failures if not enforcing scope https://review.openstack.org/591872
00:44:55 mriedem melwitt: on backporting https://review.openstack.org/#/c/591129/ to rc2, idk, would ask the release team (smcginnis or dhellmann)
00:45:27 mriedem or maybe ajaegar
00:59:02 mriedem melwitt: we don't need to backport the translations
02:01:13 openstackgerrit Merged openstack/nova master: Make Xen code py3-compatible https://review.openstack.org/591061
02:01:20 openstackgerrit Merged openstack/nova master: Update really old comments about vmware hosts managing multiple nodes https://review.openstack.org/589666
02:01:28 openstackgerrit Merged openstack/nova master: Ironic: report 0 for vcpus/memory_mb/disk_gb resources https://review.openstack.org/565841

Earlier   Later