Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-29
17:17:23 finucannot sean-k-mooney: I'm guessing we shouldn't be modifying system state
17:18:09 sean-k-mooney it depends on what the test was trying to assert but proably not
17:19:39 sean-k-mooney ah in this case its trying to determin the cache mode default i see
17:19:55 finucannot yup
17:20:02 finucannot There's another one too
17:20:14 finucannot we've got calls to 'nova.pci.utils.get_mac_by_pci_address'
17:20:34 finucannot and they're failing, resulting in lots of "Could not find the expected sysfs file for determining the MAC address of the PCI device ..." messages in logs
17:20:42 sean-k-mooney why are we using the libvir driver here and not the fake one
17:21:23 finucannot It's for e.g. the 'test_create_server_with_pci_dev_and_numa_fails' test
17:21:37 finucannot that wouldn't make sense outside of libvirt
17:21:48 sean-k-mooney right we have sriov support in the fake libvirt driver
17:21:55 finucannot yup
17:22:26 sean-k-mooney so the fake libfir driver should just overrite the disk_cachemode porperty
17:23:33 sean-k-mooney finucannot: hyperv support pci passthough and numa too by the way
17:24:02 finucannot True, but I don't know how that works so building up a fake driver for that would be a lot more work :)
17:24:24 sean-k-mooney its this test https://github.com/openstack/nova/blob/master/nova/tests/functional/libvirt/test_pci_sriov_servers.py#L244
17:25:38 sean-k-mooney so ya you could just add a mock.patch i guess
17:27:42 sean-k-mooney finucannot: https://github.com/openstack/nova/blob/master/nova/tests/functional/libvirt/base.py#L58
17:28:06 sean-k-mooney so those tests are using the real libvirt driver but with a fake connection
17:28:34 finucannot Yeah, that's what I mean when I say fakelibvirt drive
17:28:42 finucannot fakelibvirt is pretty much a simulator
17:28:46 finucannot of libvirt itself
17:29:39 sean-k-mooney i tought you ment https://github.com/openstack/nova/blob/master/nova/tests/unit/virt/libvirt/fakelibvirt.py
17:30:12 sean-k-mooney i guess that just impomentes the fake connection
17:52:56 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Stub out os_vif https://review.openstack.org/648748
17:52:56 openstackgerrit Stephen Finucane proposed openstack/nova master: Stub out privsep modules https://review.openstack.org/648747
17:53:00 finucannot sean-k-mooney: ^
17:53:04 finucannot and with that, I take my leave
17:53:17 sean-k-mooney mdbooth: your porbaly sane and have left for the weekend but shoundt https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L3945-L3969 use the disk cachemode set in the config https://github.com/openstack/nova/blob/master/nova/conf/libvirt.py#L639-L695
17:53:30 sean-k-mooney mdbooth: becasue im pretty sure it does not
17:55:42 sean-k-mooney stephenfin: not sure that returing NONE is what you want there but ill leave a comment in thereview
19:14:00 openstackgerrit Ghanshyam Mann proposed openstack/nova-specs master: Spec for API policy updates https://review.openstack.org/547850
19:14:41 fried_rolls stephenfin: You may also be interested in PrivsepFixture: https://review.openstack.org/#/c/647849/
19:17:47 fried_rice stephenfin: If your test hits an *actual* privsep-wrapped method, it'll blow up on its own.
19:29:52 openstackgerrit Eric Fried proposed openstack/nova master: Mock time.sleep() in unit tests https://review.openstack.org/648762
19:35:26 mnaser I've got a really interesting use case where I need to schedule on different GPUs with things like different *steppings*, with the possibility that a host might have different GPUs with different steppings but the *same* vendor id
19:36:18 mnaser so my questions are: does placement store records for all gpus? can I use traits to 'decorate' those gpus with those different steppings/etc? is there anything in nova that allows me to schedule based on "find me a gpu that has this trait"
19:39:42 dansmith fried_rice: answer my two little questions in there so I can make nice and +2 that
19:40:18 fried_rice ack
19:40:51 fried_rice mnaser: We don't have support for multiple VGPUs yet...
19:40:56 fried_rice and physical GPUs are not tracked in placement yet.
19:41:12 mnaser fried_rice: okay, those are physical GPUs.. hmm okay, so this might probably have to be done in some other fashion
19:41:15 fried_rice cyborg is working on making the latter happen in Train (<== Sundar)
19:41:36 fried_rice mnaser: You should be able to swing it with PCI passthrough as long as you know which PCI IDs are which
19:41:45 fried_rice mnaser: make different PCI aliases for each group.
19:41:47 dansmith same pci id I think
19:41:54 mnaser fried_rice: well in this case, I have devices that identify the same pai id
19:41:55 dansmith so you'd need aggregates I think
19:41:57 mnaser PCI ID*
19:42:12 fried_rice Sorry, not PCI IDs
19:42:17 fried_rice PCI *addresses*
19:42:25 mnaser oh that's interesting
19:42:33 mnaser I didn't know we could do it based on PCI addresses
19:42:48 dansmith that'd be pretty laborious
19:42:50 fried_rice almost certain, lmk if you need help finding that.
19:43:11 mnaser dansmith: I have automation in place to 'identify' these cards
19:43:17 fried_rice Yes, it would be laborious, especially because you now need to do individual confs per compute.
19:43:27 fried_rice no more single conf sprayed around on the computes
19:43:28 dansmith mnaser: laborious for a script then, but still
19:43:49 dansmith much cleaner if you can just arrange to have them all in unified computes and segregate them by aggregate en bulk
19:44:00 fried_rice oh, and the aliases have to be on the api node too, IIRC.
19:44:07 fried_rice that could be problematic.
19:44:24 mnaser yeah. let's just say that there isn't enough of those cards of different steppings to sit on their own groups of computes
19:44:39 dansmith mnaser: the group doesn't have to be large :)
19:44:41 mnaser I think I can build aliases like card-foo-stepping-a card-foo-stepping-b
19:45:15 fried_rice except you want card-foo-stepping-a card-foo-stepless-b, right?
19:45:39 mnaser oh I see what you mean
19:45:43 mnaser no they're all very explicit
19:46:01 mnaser there won't be a "card a, don't care what stepping" likely happening
19:48:11 mnaser fried_rice: so I can whitelist things on the compute based on address, but it looks like the alias on the API layer is product/vendor ID only
19:48:52 fried_rice mm, that makes sense of course, and would be a problem
19:49:42 dansmith and unless we auto tag gpus in placement with steppings, placement support in the future won't help with this
19:49:58 dansmith except maybe let _you_ do the tagging, but again, aggregates (however small) are a better plan I think
19:50:37 mnaser yeah I was hoping to workaround the limitations of aggregates but it might not be the best
19:50:46 mnaser I mean I can manually tag things but if there's nothing in placement..
19:51:10 mnaser I was thinking to avoid aggregates, I'd have all the same GPUs in the same box and have nova ship that out to scheduler as part of it's updates.. in some way
19:51:25 mnaser and then add a scheduler filter based on that, at least avoiding aggregates
19:51:37 dansmith I sense a pattern here...
19:55:56 openstackgerrit Merged openstack/nova master: Adds systemd detection result caching in Quobyte driver https://review.openstack.org/648093
20:01:19 fried_rice dansmith: I'll remove the 0.1->0 bit; do you want me to undo the spelling fix or leave it?
20:02:00 dansmith fried_rice: oh, I was totally seeing things
20:02:28 dansmith I thought you were converting that _to_ a nodbtestcase
20:02:29 dansmith I dunno why
20:02:42 fried_rice oh, okay :)
20:02:54 openstackgerrit Eric Fried proposed openstack/nova master: Mock time.sleep() in unit tests https://review.openstack.org/648762
20:02:54 dansmith I don't think spelling fixes belong in patches, but I shall look the other way in this case
20:03:08 fried_rice your selective blindness is appreciated.
20:45:37 openstackgerrit Eric Fried proposed openstack/nova master: Style corrections for privsep usage. https://review.openstack.org/648615
20:45:38 openstackgerrit Eric Fried proposed openstack/nova master: Improve test coverage of nova.privsep.fs. https://review.openstack.org/648602
20:45:38 openstackgerrit Eric Fried proposed openstack/nova master: Improve test coverage of nova.privsep.path. https://review.openstack.org/648601
20:45:39 openstackgerrit Eric Fried proposed openstack/nova master: Privsepify ipv4 forwarding enablement. https://review.openstack.org/635431
20:45:39 openstackgerrit Eric Fried proposed openstack/nova master: Improve test coverage of nova.privsep.fs, continued. https://review.openstack.org/648603
20:45:40 openstackgerrit Eric Fried proposed openstack/nova master: Privsep the ebtables modification code. https://review.openstack.org/635435
20:45:40 openstackgerrit Eric Fried proposed openstack/nova master: Remove unused FP device creation and deletion methods. https://review.openstack.org/635433
20:45:41 openstackgerrit Eric Fried proposed openstack/nova master: Move iptables rule fetching and setting to privsep. https://review.openstack.org/636508
20:45:41 openstackgerrit Eric Fried proposed openstack/nova master: Move adding vlans to interfaces to privsep. https://review.openstack.org/635436
20:45:42 openstackgerrit Eric Fried proposed openstack/nova master: Move router advertisement daemon restarts to privsep. https://review.openstack.org/639281
20:45:42 openstackgerrit Eric Fried proposed openstack/nova master: Move dnsmasq restarts to privsep. https://review.openstack.org/639280
20:45:43 openstackgerrit Eric Fried proposed openstack/nova master: Move setting of device trust to privsep. https://review.openstack.org/639283
20:45:43 openstackgerrit Eric Fried proposed openstack/nova master: Move calls to ovs-vsctl to privsep. https://review.openstack.org/639282

Earlier   Later