Earlier  
Posted Nick Remark
#openstack-nova - 2026-04-16
14:00:01 sean-k-mooney ok
14:00:01 stephenfin yeah
14:00:07 dansmith sean-k-mooney: I run 4.4 on jammy, but.. something earlier
14:00:33 stephenfin but that (a) is huge tech debt we really need to fix and (b) doesn't affect nova's use of tox
14:01:27 sean-k-mooney stephenfin: my new thoery is hte hardwrae where i sometimes(often) have the log setup time in tox is just cursed
14:02:27 gibi dansmith: > led to some understanding about why we're hitting this in tests only and that production should be good yeah? | yeah I think I see now why this cannot happen in production
14:02:28 sean-k-mooney nova full unit test sqiute shoudl not exectue in less time then buildign the venv to run it in... py3: OK (508.14=setup[284.11]+cmd[193.47,23.86,6.70] seconds)
14:02:47 dansmith gibi: ack, well, sorry for the goose chase, but I feel better :)
14:03:25 stephenfin bauzas: Can do. What will that look like? I'd rather not duplicate what's in tox.ini in our docs since they're liable to drift, so maybe I can just say you need at least tox 4.x available (since it'll bootstrap itself if it needs a newer version)?
14:03:30 gibi dansmith: don't feel bad about it. Your question actually lead to a deeper understanding of the situation
14:03:31 stephenfin s/will/should/
14:03:55 bauzas gibi: dansmith: I hadn't yet reviewed, but thanks for the discussion, I'll look at the patch
14:04:46 gibi dansmith: the next similar area I want to understand more is the CellDatabases fixture that implements some weird routing of DB connections via hooking into the target_cell call
14:05:03 bauzas stephenfin: there are two problems to solve here : 1/ documenting the fact that in Hibiscus, we bumped to 4.28.0 (should be easy addition to dev-env.rst), 2/ before merging the patch, making sure that we don't create devstack problems
14:05:18 dansmith gibi: ack, there are some acrobatics in there for sure
14:06:48 stephenfin (2) isn't an issue and will be confirmed by CI and the fact that other projects have already done see (e.g. ironic https://github.com/openstack/ironic/blob/master/tox.ini#L2)
14:07:22 stephenfin I can also walk through how tempest is (wrongly) using tox and why it depends on tox 3.x, but my WIP patches probably explain it better
14:08:10 stephenfin https://review.opendev.org/q/topic:%22rework-tempest-install%22+is:open
14:08:23 sean-k-mooney ~/repos/nova-2$ tox -e py3 -r
14:08:25 sean-k-mooney .tox create: /home/debian/repos/nova-2/.tox/.tox
14:08:27 sean-k-mooney .tox installdeps: tox >= 4.28.0
14:08:33 sean-k-mooney so that usign the tox provided by devstack
14:08:39 sean-k-mooney on stephenfin's patch
14:08:56 sean-k-mooney so the pone we have pinned it too has the supprot to bootstracp to the requried version if needed
14:09:10 sean-k-mooney im waiting for that to complete
14:12:20 bauzas there are a long list of projects that still have 3.18.0 as minimum https://codesearch.openstack.org/?q=minversion%20%3D&i=nope&literal=nope&files=tox.ini&excludeFiles=
14:12:41 bauzas again, I'm not opposed to the upgrade, I just want us to be careful
14:13:33 bauzas my life didn't change when I upgraded to 4.x apart the fact I stupidely forget every day that I need to add doubledashes on posargs :)
14:15:22 dansmith I've been using 4.x for a long time and I still do that :)
14:19:33 stephenfin bauzas: Hmm, this dev-env doc is pretty old 😅 It references RHEL 6 and easy_install 🙈
14:19:56 sean-k-mooney ya...
14:20:00 stephenfin I'm happy to rewrite it, but can I stick it in a follow-up since I suspect it'll need a few rounds of review
14:20:15 sean-k-mooney that compelte fien by the way py3: OK (478.49=setup[271.33]+cmd[181.72,18.91,6.54] seconds)
14:21:01 sean-k-mooney so the bootstrap and execution works end ot end with the tox provided by devstack
14:21:43 sean-k-mooney without impact the actul tox version that devstack provides
14:21:46 sean-k-mooney tox --version
14:21:48 sean-k-mooney 3.28.0 imported from /opt/stack/data/venv/lib/python3.13/site-packages/tox/__init__.py
14:34:27 stephenfin sean-k-mooney: the dev-env doc references fake compute. That's not a thing any more, right?
14:34:37 sean-k-mooney yes it is
14:34:51 sean-k-mooney we are using them to test teh eventlet removeal with rally
14:35:11 stephenfin Oh, okay. I thought the fake driver was only used for functional tests
14:35:24 sean-k-mooney nope it can be used as a "real" driver
14:35:48 sean-k-mooney typeicly without networkign but there is technially a fake neturon driver too
14:36:40 sean-k-mooney https://github.com/openstack/devstack/blob/master/lib/nova_plugins/hypervisor-fake still works more or less
14:41:29 stephenfin TIL
14:58:07 opendevreview Stephen Finucane proposed openstack/nova master: docs: Update development-environment guide https://review.opendev.org/c/openstack/nova/+/984956
14:58:13 stephenfin bauzas: sean-k-mooney: ^
14:58:31 stephenfin dansmith: you might tell me if the (minimal) macOS instructions are correct (I've no way to verify)
14:59:57 dansmith stephenfin: ack, joining a call but will look async
15:00:04 stephenfin ty 🙏
16:31:09 Uggla gibi, fyi regarding bug https://bugs.launchpad.net/nova/+bug/2145783 found in the spec : While it would possible to support defining different resource_class names for different VFs under the same parent PF, this is considered bad practice and unnecessary complexity. Such configuration will be rejected.
16:31:10 Uggla https://specs.openstack.org/openstack/nova-specs/specs/zed/approved/pci-device-tracking-in-placement.html
16:45:20 gibi Uggla: that sounds good at least it was outscope due to complexity not due to infeasibility
16:46:17 gibi the bad pratice holds for NICs but it seems it does not hold for GPUs
16:46:34 Uggla gibi, yes we might revisit that as to me it makes sens for GPUs (was not the case at that moment).
16:46:34 gibi so I'm OK to get a new spec that adds this capability
16:48:13 Uggla gibi, I'd like first an answer from the reporter. Maybe he does not need it.
16:48:54 gibi yeah make sense
16:49:43 Uggla gibi, do you think it is something to share at the PTG ? (assuming I'll find a slot)
16:51:53 opendevreview Stephen Finucane proposed openstack/nova master: docs: Update development-environment guide https://review.opendev.org/c/openstack/nova/+/984956
16:53:40 opendevreview Stephen Finucane proposed openstack/nova master: Fix functional tests and mypy on macOS https://review.opendev.org/c/openstack/nova/+/937727
16:53:42 gibi Uggla: Why not. Put it at the end of the Agenda like "best effort topic if we have time"
16:54:14 gibi and either we touch it next week or not. If not then we can bring it up on the weekly meeting when the spec is raised
16:54:27 Uggla gibi 👍
16:54:55 dansmith stephenfin: oh I was just running unit tests anyway, which is why I don't see those
16:55:43 stephenfin Ah, okay. I wonder why the author of the patch didn't see (and fix) those other issues. Anyway, not related as you say
16:56:40 dansmith well, one of mine is because libcrypt is not available (which also fails on oslo).. I assume that should be a skip though, I just haven't cared enough since it's one failure and easy to ignore
16:58:21 dansmith I usually run unit/functional in my fedora vm, I just like to be able to run targeted single-test things natively sometimes so I don't really care or notice that a few tests fail for whatever reason
17:00:09 dansmith stephenfin: the other failure is " AttributeError: module 'socket' has no attribute 'AF_PACKET'"
17:00:17 dansmith which I assume is because AF_PACKET is a linux/netlink thing that isn't portable
17:00:24 dansmith so again a skip seems reasonable
17:02:48 dansmith (not netlink, just not POSIX)
17:02:49 stephenfin looks like it https://github.com/python/typeshed/blob/bd18cc640cba4dadc51ac9a5157b79ff6adf5de3/stdlib/_socket.pyi#L478
17:03:00 dansmith yah
17:08:02 opendevreview Dan Smith proposed openstack/nova master: Skip some unit tests on macOS https://review.opendev.org/c/openstack/nova/+/985014
17:08:11 dansmith stephenfin: ^
17:08:50 stephenfin +2
17:09:15 opendevreview Merged openstack/nova master: Reproduce bug #2108974: keypairs lost during cross-cell resize https://review.opendev.org/c/openstack/nova/+/981557
20:07:44 sean-k-mooney Uggla: you can defien diffent resouce class names per VF today
20:08:01 sean-k-mooney you jsut have to use the address to specify it
20:08:38 sean-k-mooney i.e. in the devspec you can match on the vf adress and spcify which resouce class to report
20:09:05 sean-k-mooney you can use the fact that the adress can have bash globs or a regex to apply that to sets of VFs too
20:09:48 sean-k-mooney or at least you shoudl be able to unless we scoped that out when we did the implemeiont
20:10:53 sean-k-mooney https://docs.openstack.org/nova/latest/configuration/config.html#pci.device_spec
20:11:04 sean-k-mooney the config options were desigend to enabeld that usecase
20:11:22 sean-k-mooney but i dont know if we are properly handling this in rhe resouce tracker
20:11:50 sean-k-mooney we shoudl be but the pci stat pools need to prperly handel that grouping
20:12:40 sean-k-mooney it hilgy likely we never tested it and it broken as a result but its totally expressable today vai our config options
20:15:05 sean-k-mooney Uggla: i have not had time to add pci grouping to the nova ptg but if we wanted to talk about different VF in the same pf having diffent rsouce classes for gpus usecases ti woudl make sense to talk about it toghetehr with nova pci grouping
20:15:16 sean-k-mooney i had ot parly implemnt that for that feature anyway
20:15:37 sean-k-mooney since i want to supprot creating groups fo VFs from teh same or diffent PFs
20:19:04 sean-k-mooney i was mainly testing with takign 64 VF that i was subdeviding into groups
20:19:52 sean-k-mooney a groups of 8 and groups of 4 would have 2 diffent resocues classes even if they are effectivly the same device
20:21:06 sean-k-mooney as long as all host that report CUSTOM_PCI_GROUP_NICX8 provide the same VF type for that i.e. so they are interchangable form the schdluer point of view
20:21:45 sean-k-mooney its ok to report other VF form the same card with a differnt type.
20:21:58 sean-k-mooney *differnt resouce class.
20:23:40 sean-k-mooney if you had a gpu that you partioned into 3 Mig device 1 that used half the card an 2 that used 1/4 each
20:24:20 sean-k-mooney the correct way to model that in placment via nova ro cyborg would be 1 RP for the PF with an inveotyr of 2 of one resocue class and 1 of a diffent one
20:26:36 sean-k-mooney being very hand wavy that is the eventual plan for how to do that in cybrog but not right away.
21:22:11 opendevreview Merged openstack/nova master: Fix keypairs lost during cross-cell resize https://review.opendev.org/c/openstack/nova/+/981558

Earlier   Later