Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-29
17:05:33 openstack Launchpad bug 1777482 in python-novaclient (Ubuntu) "console-log ERROR (TypeError): write() argument must be str, not bytes" [Medium,Triaged]
17:06:31 mnaser python-openstackclient seems to not use the codec fanciness. https://github.com/openstack/python-openstackclient/blob/4bde9af89251431791fc8d69fe09d5e17a8fba8f/openstackclient/compute/v2/console.py#L64
17:06:34 mnaser I dunno what's the best avenue
17:13:14 sean-k-mooney finucannot: of course i disagree. what wat the question so i know what postion i am ment to be taking :)
17:16:23 sean-k-mooney finucannot: oh mocking in functional tests. it depends on what you are mocking but in general you shoul dnot mock in functional test but you might use different backend implementations
17:16:31 sean-k-mooney or test fixtures
17:16:52 finucannot sean-k-mooney: I'm seeing calls through to nova.privsep.utils.supports_direct_io
17:17:05 finucannot from 'File "nova/virt/libvirt/driver.py", line 418, in disk_cachemode'
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

Earlier   Later