Earlier  
Posted Nick Remark
#openstack-nova - 2025-03-31
14:29:19 sean-k-mooney zigo: you can deploy your ceph so that there is no routeablity form the vm subnets
14:29:31 sean-k-mooney but there is routablity on the compute nodes
14:29:34 zigo That's the case already. :)
14:30:32 zigo But then, the API will be still available, I was hoping for it to say "404: cephfs API not activated, please use virtio-fs instead" or something ...
14:32:06 sean-k-mooney no
14:32:14 sean-k-mooney because manilla does not know about virtiofs
14:32:31 sean-k-mooney that an internal implemation detail of nova (sepcrically the libvirt driver)
14:33:45 sean-k-mooney zigo: i belive there might be a way to limit what info is shown to nova (via the service role) and the user (member/reader)
14:33:51 sean-k-mooney on the manilla side
14:42:07 opendevreview Dan Smith proposed openstack/nova master: Invalidate PCI-in-placement cached RPs during claim https://review.opendev.org/c/openstack/nova/+/944149
14:42:07 opendevreview Dan Smith proposed openstack/nova master: Support "one-time-use" PCI devices https://review.opendev.org/c/openstack/nova/+/943816
14:42:08 opendevreview Dan Smith proposed openstack/nova master: Add one-time-use devices docs and reno https://review.opendev.org/c/openstack/nova/+/944262
14:42:08 opendevreview Dan Smith proposed openstack/nova master: DNM: Test nova with placement alloc fix https://review.opendev.org/c/openstack/nova/+/945626
14:48:53 dansmith gibi: are you intending to hold off approving/merging OTU until after discussion at the PTG?
14:49:19 sean-k-mooney are there open desgin decisions ?
14:49:54 sean-k-mooney i.e. that need dicsussion at the ptg
14:49:58 dansmith not that I'm aware of, and the spec is merged, I just had the thought that maybe gibi was expecting to wait
14:50:01 sean-k-mooney or is it just normal code review that needed
14:50:07 dansmith just normal review, I think
14:50:12 sean-k-mooney ack
14:50:23 dansmith it's on the PTG for discussion, but TBH i was hoping to have it merged before then
14:50:32 dansmith since I'll be out for part of it (and the week after)
14:50:33 sean-k-mooney i personally have not had time to loop back to the impl much
14:50:57 gibi dansmith: I think we can progress with the normal code review. Right now I don't see any open questions on the spec level
14:50:59 sean-k-mooney but i didnt have any huge concern with the approch that was nto adressed in the spec
14:51:30 dansmith gibi: ack, I agree, I just realized I wasn't sure what others were actually thinking
14:51:42 sean-k-mooney dansmith: the only thing that comes to mind really are your expermient with using virt-rng ot try and test this in ci
14:52:06 dansmith sean-k-mooney: I've already got the images modified on vexx, and was planning to try to work on that next sprint
14:52:07 gibi sean-k-mooney: I still have the intention to test it with IGB locally
14:52:22 sean-k-mooney that not blocking i just dont know fi you want to present that approch to folks
14:52:27 dansmith but I also don't want to hold this up for that, since that is more just general PCI testing, and OTU in tempest will be a bit difficult
14:52:29 sean-k-mooney dansmith: oh cool good to know
14:52:57 sean-k-mooney dansmith: i was more thinking did we want to dicuss what else we could test with that
14:53:05 dansmith OTU in tempest is probably not doable because I need a single device, a dedicated flavor, no parallelism, etc, so I suspect whitebox is the best option
14:53:42 sean-k-mooney it might be possibel in upstream tempest but i dont think anyone would object to whitebox
14:54:04 sean-k-mooney anyway if we keep the ptg session this is what i was expecting to come up
14:54:27 dansmith the problem is tempest would need to know the alias in order to create the flavor in the one test we use it, or we'd need to communicate another flavor devstack setup that is only for that one test
14:54:31 sean-k-mooney not really OTU itself but how can we improve passhtough testing in general
14:54:34 dansmith but yeah, maybe we use the PTG to discuss testing
14:54:49 sean-k-mooney like we never finish the mdev testing work
14:55:06 sean-k-mooney we have your mtty devstack supprot just missing the nova bit to use it
14:55:25 dansmith ack, I thought bauzas had ruled that out
14:55:27 dansmith but it'd be nice
14:55:40 sean-k-mooney i think bauzas was just to busy to finish it
14:55:48 dansmith okay
14:55:54 sean-k-mooney i dont know of anything blockign completing the work
14:55:56 bauzas I'm pretty burned about vgpu but I can try to update my mtty series
14:56:49 sean-k-mooney the other thing gibi and i were hopign to do is after a coulple of the provider get to epoxy we would like to see if we can get image with igb enbaled
14:56:58 sean-k-mooney so we can test sriov
14:57:07 sean-k-mooney not sure when that will happen but its related.
14:57:18 Uggla bauzas, maybe you can offload some vgpu stuff to me.
14:59:12 sean-k-mooney dansmith: on a related note but changing the topic slightly https://review.opendev.org/c/openstack/placement/+/945465 is being tracked as a bugfix, but do you think its a backportable change or master only
14:59:31 gibi https://etherpad.opendev.org/p/nova-2025.2-ptg#L378
14:59:53 dansmith sean-k-mooney: I think it's backportable and would be a good candidate, personally, since it's very self-contained and the bug really sucks for operators, IMHO
15:00:18 dansmith sean-k-mooney: but, I have not been able to test that it actually fixes the nova migration problems yet since I need two computes to do it
15:00:35 sean-k-mooney ack my follow up is if that backportable do we need nova work for the existing nova bug or do you think cold migration ectra woudl just start working?
15:00:51 dansmith I believe this should make it just work on the nova side
15:01:42 sean-k-mooney ack, not that our downsteam qe have a lot of capsity for upstream work but we might want to talk to them about how we coudl test the previously broken operation in upstream tempest
15:02:23 sean-k-mooney well or whitebox
15:02:32 dansmith again, this requires putting the compute node into overcapacity state with an allocation_ratio change, so I don't really think we can do that in upstream parallel tempest
15:02:38 dansmith whitebox potentially
15:04:34 sean-k-mooney tempest has the ida of serial test that run one by one. that might help here but many of these edge cases have the potentil to conflict wth other test so i guess we would need to be carful about how we would test this
15:05:05 dansmith yeah, true.. it just seems sort of off the table for tempest by scope too, but perhaps not
15:05:38 sean-k-mooney the other concern i have is will this break any current functionl tests if we have repoducer for any of the nova bugs
15:05:44 sean-k-mooney i dont think we do
15:06:02 sean-k-mooney but if you fix it in placment it will presumable sto raising an error with the placement driect fixture
15:06:14 dansmith if we do, I'm not aware of them
15:06:51 gibi having a placement only tempest test for the overallocation fix could be written to be independent from any other test by creating a separate RP, but I'm not sure that worth it compared to a full nova migration test with overallocation.
15:07:15 sean-k-mooney ok in that case i realy dont have any other question related to this.
15:07:27 sean-k-mooney gibi: that could be done but gabit kind fo does that already right
15:07:38 gibi yeah
15:07:40 dansmith gibi: yeah could definitely do that but the placement functional tests feels just as good for that to me
15:08:01 gibi I a big believer in functional tests :)
15:08:08 gibi I'm
15:11:04 dansmith certainly for this they're plenty adequate I think
16:19:10 dansmith sean-k-mooney: didn't you have a recipe for using the upstream ansible playbooks to deploy multinode devstack locally?
16:54:23 ivveh hey, im looking to be pointed in the correct direction. i want to nova to build my custom xmls. like hooks or some other method that is supported by nova and preferably has a framework for that. i'd like to avoid modifying the libvirt driver as much as possible
17:05:32 sean-k-mooney dansmith: sorry yes i have
17:07:47 sean-k-mooney dansmith: https://github.com/SeanMooney/ard/blob/master/ansible/deploy_multinode_devstack.yaml is the playbook that does it that was driven by molecule with vagrant_libvirt to provdie the vms https://github.com/SeanMooney/ard/blob/master/molecule/default/molecule.yml
17:08:11 dansmith ah with vagrant
17:08:24 sean-k-mooney you didnt need vagrant
17:08:41 sean-k-mooney the playbooks could work with any servers once you hadd ssh access
17:09:28 sean-k-mooney so like i provisioned some server internally for vdpa testing and just poited the palybooks at it with an inventory file
17:09:45 sean-k-mooney https://github.com/SeanMooney/ard/tree/master/examples/vdpa
17:11:13 sean-k-mooney i wrote 3 roles devstack_{common,compute,controller} that wrappted the upstream devstack roles form teh gate jobs
17:11:17 sean-k-mooney https://github.com/SeanMooney/ard/tree/master/ansible/roles
17:12:49 sean-k-mooney dansmith: its been like 3+ years since i used any of this
17:12:59 sean-k-mooney it proably still wroks but i havent been maintining it
17:13:15 sean-k-mooney dansmith: was there a specific reason you asked
17:14:22 dansmith sean-k-mooney: I was struggling through re-re-remembering the multinode devstack rain dance
17:14:28 dansmith but I got it figured out whilst waiting
17:14:37 sean-k-mooney ah ok
17:14:44 dansmith sean-k-mooney: gibi: can confirm that just that placement change fixes the nova migrate-while-over-capacity bug
17:14:52 sean-k-mooney i have some downstream docs of the process with bash
17:15:09 dansmith I was able to repro, then literally swapped placement to that commit, restarted, retried the same migration and it went, confirmed, all good
17:15:18 sean-k-mooney and one of my team recently wrote an ansible playbook to deploy multi node devstack on our internal cloud i can ping you does internally
17:15:33 sean-k-mooney dansmith: oh nice
17:16:24 dansmith sean-k-mooney: thanks, I need to formalize my own notes, because I have some of my own scripting and making things work with those is most ideal,
17:16:31 dansmith I just suck at persisting the notes after I get it workin,
17:16:39 dansmith but I'm going to do that now

Earlier   Later