Monday, 2025-03-31

opendevreviewZhang Hua proposed openstack/nova stable/2024.1: Fix deepcopy usage for BlockDeviceMapping in get_root_info  https://review.opendev.org/c/openstack/nova/+/92669606:52
opendevreviewZhang Hua proposed openstack/nova stable/2024.1: Fix device type when booting from ISO image  https://review.opendev.org/c/openstack/nova/+/94581606:52
zigosean-k-mooney: Sorry for I didn't write your first name correctly on my message to the list. :/13:10
zigoAnd thanks a lot for your reply.13:11
zigoThere's still things I don't understand.13:11
zigoManila has multiple modes, one is the "generic" one that I used to use, and the other one that has to be used for CephFS.13:11
zigoWhen you write that I have "nothing to do", I suppose that is, compared to the non-generic mode, right?13:12
sean-k-mooneyzigo: it fine i dont mind i technically didnt either its "seán" not "sean" but typeing the foda over the a often breaks things :)13:13
sean-k-mooneyzigo: when i say there is noghting to do i mean nova should not need to care how manilla is configured13:14
zigoYeah, but I need to somehow teach my management software to configure Manila for virtio-fs... :)13:14
sean-k-mooneyits just useing the info form the share export/attachment (whatever its called in manilas api)13:14
sean-k-mooneymanila does nto need special config13:15
sean-k-mooneythe way this is working is we are attachign the manila share to the compute host and then using virtio-fs to passthough that "local" filestytem to the vm13:15
zigoYeah, got that point.13:16
zigoThough, for example, in manila.conf's share_driver, what should I write?13:16
sean-k-mooneyfor cephfs the compute node need to access to the ceph cluster for that to work. with the generic driver the comptue node wound need to have network connectivity with the vm that runing the nfs server13:16
sean-k-mooneyzigo: Uggla can correct men if im wrong but it should not need any config changes form using the backend without this feature13:17
sean-k-mooneyzigo: as far as im aware, your installer should not need to do any config on the manilla side and the only config change needed on nova are the manilla keystone auth  parmaters https://docs.openstack.org/nova/latest/configuration/config.html#manila13:20
sean-k-mooneywe have only one manila specific option https://docs.openstack.org/nova/latest/configuration/config.html#manila.share_apply_policy_timeout13:21
* zigo is in meeting, will read soon13:21
carlosszigo: ++ on sean-k-mooney's info. No additional configuration is needed in Manila. You would only need to have the backend properly configured as in any deployment other deployment, create a share and provide it during the nova attachment process, then nova and manila will do the rest for you (creating access rules, locking the share, locking the access rules and so on)13:24
sean-k-mooneyif your using the generic driver the main limiation is the share network needs to be routeable form the compute nodes13:26
sean-k-mooneybasically meaning it should be a neutron external network unlss floating ips work with manilla?13:26
UgglaYes only a manila section like the one from cinder but with name [manila]13:27
Ugglaso nova could get the enpoint + cred to access manila.13:28
sean-k-mooneyUggla: i notcied we dont seam to have a tempest job for this in nova yet13:28
sean-k-mooneyor at least i didnt see this enabled in any of our exsitign jobs13:29
sean-k-mooneydo you have patches for that still pending?13:29
Ugglayep I know and I'm guilty about it. I worked on them, but did not complete them yet.13:29
sean-k-mooneyit would be nice ot test cephfs in our ceph job and the generic driver with lvm in one of the ohters13:29
sean-k-mooneyack13:29
sean-k-mooneyUggla: well you did a lot last cycle. i was more asking to see if we could provide a refence to zigo of devstack cofniguration for ceph and nfs via cinder lvm13:30
sean-k-mooneyso they could take a look at how it works13:30
Ugglasean-k-mooney, but there are discussion to have this effort done by the manila team.13:31
Ugglaor part of the effort.13:31
sean-k-mooneyit could be but we should be testing it in our jobs too13:31
UgglaOf course I can provide zigo how to configure with devstack, so he could transpose to his configuration.13:32
sean-k-mooneyi dont think we need new jobs in nova just our existing jobs shoudl be tweeked13:32
sean-k-mooneyUggla: ya i think that would help13:32
Ugglabtw there is a fn job with the sdk which is doint minimal testing against tempest. 13:33
Ugglas/doint/doing13:33
zigosean-k-mooney: If I'm going to use virtio-fs, that's precisely because I do not want to use the generic driver.14:21
zigoWhat I don't get though, is if I'm using the "normal" cephfs driver, I do not want my users to be able to use cephfs direct connection from their VMs.14:23
zigoFor us, the Ceph backplane is *not* accessible from the VMs.14:23
zigo(or purpose, for security reasons).14:23
zigoSo is there a way to desactivte it?14:23
zigoUggla: ^14:28
sean-k-mooneyzigo: you can deploy your ceph so that there is no routeablity form the vm subnets14:29
sean-k-mooneybut there is routablity on the compute nodes14:29
zigoThat's the case already. :)14:29
zigoBut 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:30
sean-k-mooneyno14:32
sean-k-mooneybecause manilla does not know about virtiofs14:32
sean-k-mooneythat an internal implemation detail of nova (sepcrically the libvirt driver)14:32
sean-k-mooneyzigo: 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
sean-k-mooneyon the manilla side14:33
opendevreviewDan Smith proposed openstack/nova master: Invalidate PCI-in-placement cached RPs during claim  https://review.opendev.org/c/openstack/nova/+/94414914:42
opendevreviewDan Smith proposed openstack/nova master: Support "one-time-use" PCI devices  https://review.opendev.org/c/openstack/nova/+/94381614:42
opendevreviewDan Smith proposed openstack/nova master: Add one-time-use devices docs and reno  https://review.opendev.org/c/openstack/nova/+/94426214:42
opendevreviewDan Smith proposed openstack/nova master: DNM: Test nova with placement alloc fix  https://review.opendev.org/c/openstack/nova/+/94562614:42
dansmithgibi: are you intending to hold off approving/merging OTU until after discussion at the PTG?14:48
sean-k-mooneyare there open desgin decisions ?14:49
sean-k-mooneyi.e. that need dicsussion at the ptg14:49
dansmithnot that I'm aware of, and the spec is merged, I just had the thought that maybe gibi was expecting to wait14:49
sean-k-mooneyor is it just normal code review that needed14:50
dansmithjust normal review, I think14:50
sean-k-mooneyack14:50
dansmithit's on the PTG for discussion, but TBH i was hoping to have it merged before then14:50
dansmithsince I'll be out for part of it (and the week after)14:50
sean-k-mooneyi personally have not had time to loop back to the impl much14:50
gibidansmith: I think we can progress with the normal code review. Right now I don't see any open questions on the spec level14:50
sean-k-mooneybut i didnt have any huge concern with the approch that was nto adressed in the spec14:50
dansmithgibi: ack, I agree, I just realized I wasn't sure what others were actually thinking14:51
sean-k-mooneydansmith: the only thing that comes to mind really are your expermient with using virt-rng ot try and test this in ci14:51
dansmithsean-k-mooney: I've already got the images modified on vexx, and was planning to try to work on that next sprint14:52
gibisean-k-mooney: I still have the intention to test it with IGB locally14:52
sean-k-mooneythat not blocking i just dont know fi you want to present that approch to folks14:52
dansmithbut 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 difficult14:52
sean-k-mooneydansmith: oh cool good to know14:52
sean-k-mooneydansmith: i was more thinking did we want to dicuss what else we could test with that14:52
dansmithOTU 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 option14:53
sean-k-mooneyit might be possibel in upstream tempest but i dont think anyone would object to whitebox14:53
sean-k-mooneyanyway if we keep the ptg session this is what i was expecting to come up14:54
dansmiththe 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 test14:54
sean-k-mooneynot really OTU itself but how can we improve passhtough testing in general14:54
dansmithbut yeah, maybe we use the PTG to discuss testing14:54
sean-k-mooneylike we never finish the mdev testing work14:54
sean-k-mooneywe have your mtty devstack supprot just missing the nova bit to use it14:55
dansmithack, I thought bauzas had ruled that out14:55
dansmithbut it'd be nice14:55
sean-k-mooneyi think bauzas  was just to busy to finish it14:55
dansmithokay14:55
sean-k-mooneyi dont know of anything blockign completing the work14:55
bauzasI'm pretty burned about vgpu but I can try to update my mtty series14:55
* gibi adding a mdev, PCI testing topic to the PTG...14:56
sean-k-mooneythe 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 enbaled14:56
sean-k-mooneyso we can test sriov 14:56
sean-k-mooneynot sure when that will happen but its related.14:57
Ugglabauzas, maybe you can offload some vgpu stuff to me.14:57
sean-k-mooneydansmith: 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 only14:59
gibihttps://etherpad.opendev.org/p/nova-2025.2-ptg#L37814:59
dansmithsean-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, IMHO14:59
dansmithsean-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 it15:00
sean-k-mooneyack 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
dansmithI believe this should make it just work on the nova side15:00
sean-k-mooneyack, 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 tempest15:01
sean-k-mooneywell or whitebox15:02
dansmithagain, 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 tempest15:02
dansmithwhitebox potentially15:02
sean-k-mooneytempest 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 this15:04
dansmithyeah, true.. it just seems sort of off the table for tempest by scope too, but perhaps not15:05
sean-k-mooneythe other concern i have is will this break any current functionl tests if we have repoducer for any of the nova bugs15:05
sean-k-mooneyi dont think we do15:05
sean-k-mooneybut if you fix it in placment it will presumable sto raising an error with the placement driect fixture15:06
dansmithif we do, I'm not aware of them15:06
gibihaving 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:06
sean-k-mooneyok in that case i realy dont have any other question related to this. 15:07
sean-k-mooneygibi: that could be done but gabit kind fo does that already right15:07
gibiyeah15:07
dansmithgibi: yeah could definitely do that but the placement functional tests feels just as good for that to me15:07
gibiI a big believer in functional tests :)15:08
gibiI'm15:08
dansmithcertainly for this they're plenty adequate I think15:11
dansmithsean-k-mooney: didn't you have a recipe for using the upstream ansible playbooks to deploy multinode devstack locally?16:19
ivvehhey, 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 possible16:54
sean-k-mooneydansmith: sorry yes i have 17:05
sean-k-mooneydansmith: 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.yml17:07
dansmithah with vagrant17:08
sean-k-mooneyyou didnt need vagrant17:08
sean-k-mooneythe playbooks could work with any servers once you hadd ssh access17:08
sean-k-mooneyso like i provisioned some server internally for vdpa testing and just poited the palybooks at it with an inventory file17:09
sean-k-mooneyhttps://github.com/SeanMooney/ard/tree/master/examples/vdpa17:09
sean-k-mooneyi wrote 3 roles devstack_{common,compute,controller} that wrappted the upstream devstack roles form teh gate jobs17:11
sean-k-mooneyhttps://github.com/SeanMooney/ard/tree/master/ansible/roles17:11
sean-k-mooneydansmith: its been like 3+ years since i used any of this17:12
sean-k-mooneyit proably still wroks but i havent been maintining it17:12
sean-k-mooneydansmith: was there a specific reason you asked17:13
dansmithsean-k-mooney: I was struggling through re-re-remembering the multinode devstack rain dance17:14
dansmithbut I got it figured out whilst waiting17:14
sean-k-mooneyah ok 17:14
dansmithsean-k-mooney: gibi: can confirm that just that placement change fixes the nova migrate-while-over-capacity bug17:14
sean-k-mooneyi have some downstream docs of the process with bash17:14
dansmithI was able to repro, then literally swapped placement to that commit, restarted, retried the same migration and it went, confirmed, all good17:15
sean-k-mooneyand one of my team recently wrote an ansible playbook to deploy multi node devstack on our internal cloud i can ping you does internally17:15
sean-k-mooneydansmith: oh nice17:15
dansmithsean-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
dansmithI just suck at persisting the notes after I get it workin,17:16
dansmithbut I'm going to do that now17:16
ivvehas more context to my previous question is that i want to include iothread stanza into the xml (for now)17:18
sean-k-mooneydansmith: the main parts of multi node are syncing the tls/ceph data, exchantign the ssh keys/known_hosts, ntp sync and updating /etc/hosts before deploying the comptues. then adding a discover host at the end17:19
dansmithyeah, it was just the CA stuff I forgot this time17:20
dansmithas soon as it failed, I knew the problem, but then had to remember to copy the CA dir *and* the bundle, lest it would nuke the latter on stacking the subnode17:20
sean-k-mooneydid you know that tls is appreantly not on by default in devstack. i always  used the ci jobs as a basis for mine17:21
sean-k-mooneybut if you use devstack by default it does not enabel the tls-proxy17:21
dansmithyeah, I have it on my base node though, so..17:21
gibidansmith: nice test results17:21
dansmithgibi: also works for the case where reserved is changed to cover the node, so that covers the OTU case too17:22
sean-k-mooneyivveh: we do not have any hook point in nova to allow you to modify the xml. that is a very intetional decsions17:22
sean-k-mooneyivveh: if you want to modify the xml you are required to modify the virt driver because we do not want to supprot external customisation fo the domain thoguh any kind of hooks17:23
sean-k-mooneyivveh: what is it you are actully trying to do to the xml17:24
gibidansmith: cool17:25
dansmithI was hoping to have tested the migration allocation thing for real last week but ran out of time. Luckily my monday morning meeting was canceled I could get a jump on it17:29
ivvehsean-k-mooney: add <iothreads/>17:46
ivveh(as i couldn't find it anywhere in the extraspecs or other methods of modifying the xml) but feel free to point me in the correct direcion if iothreads do exist, i need to point them out and pin on them, maybe some other stuff too17:48
sean-k-mooneyits not currently supproted. we had a blueprint to add it a year ago but the person working on it did actuly push any code17:49
ivvehgotcha, would it be as an extraspec or some other method?17:49
sean-k-mooneywhat i was suggeting was to allway allcoate 1 and make it float over the cpu_share_set17:50
sean-k-mooneywe discussed if we shoudl supprot more then one but the advice form our virt team was no17:50
sean-k-mooneythey suggested that in the future 1 per cinder volume might make sense but the high level degisn we had dicussed in teh past was 1 keep it simple and start with all vms having 1 iothread17:51
sean-k-mooney2 in the future add a flavor extra spec to opt into one per cinder volum eif needed17:51
sean-k-mooney3 possible allow this to be set on the image or config instead (TBD if/when we add the 1 per cinder volume feature)17:52
sean-k-mooneyhttps://review.opendev.org/c/openstack/nova/+/939254 is the most recent attempt17:52
sean-k-mooneyhttps://blueprints.launchpad.net/nova/+spec/iothreads-for-instances17:53
ivvehthanks, ill have a look17:53
sean-k-mooneythis version is adding a config option to contol the behvior17:53
sean-k-mooneyah the blueprint has the link to the ptg dicssion form last cyle https://etherpad.opendev.org/p/nova-2025.1-ptg#L68617:54
ivvehyeah, i wouldn't know how to do it at this point, i was thinking of having a pool of cores for this use and somehow allocate to those cores via vms (no matter how many volumes they had). i also need to do the same thing for virtiofsd (a different more complex story as i also have to figure out how to force it to use fifo or change some code)17:55
sean-k-mooneyivveh: so this level of low level customstion of the domain is onlyt possibe via modifying the in tree driver17:56
sean-k-mooneyupstream we consier any out of band modification of the dmoain to make the vm unsupported17:56
ivvehyeah, thats what i thought. i was hoping to avoid it, but.. 17:56
sean-k-mooneyivveh: we only added the iniall use of virtiofs this cycle17:57
sean-k-mooneyso we have not looekd at any kind of affinity for vritio fs deamon17:57
ivvehmy usecase is very specific as i know how many and how large my vms can be and i wanna assign them a certain amount of cores17:57
sean-k-mooneyi see. that not really a usecase that is very compatible with cloud computeing :)17:58
ivvehdepends on what flavors you rent ;)17:58
ivvehbut i get your point17:58
sean-k-mooneywaht i mean is we allow you to express constratis like "i want this vm to have dedicated pinned cpus" and obviosly you can create falvors with X amount of cpus17:59
sean-k-mooneybut we intentioally do not allow you to do direct maping of logcial cpus to host cpus17:59
ivvehyeah no, i understand openstack needs to have its constraints, its normal and acceptable17:59
sean-k-mooneynova can do that internlly but its not exposed directly in the flavor17:59
ivvehfor shenenings you have to go custom18:00
sean-k-mooneywe talked about having a pool for iothread. but we didnt want to have to schdule on them18:00
ivvehi think either way, it would be great for nova to have a iothread pool that nova/cinder could take resources from (as these days defaults aren't enough)18:01
ivvehwould be great to have like flavors with iothread spec extraspec for example, to be able to utilize those resources, or not18:03
sean-k-mooneywhen we dicussed it the idea was for it to just be an addtion set of core, taht woould default to cpu_shared_set  if not defiend in the config18:03
sean-k-mooneyi.e. add a iothread_set to nova. those cpu could overlap with cpu_shared_set but now cpu_dedicated_set. we kind of felt that was too complex to start with18:04
sean-k-mooneythat does not mean we could not add that later18:04
ivvehyea if you use cpu_shared_set and vms are pinned then they would always be free for stuff like iothreads or virtiofsd18:06
sean-k-mooneyso we already supprot moving the emulator thread to cpu_shared_set for pinned vms18:06
sean-k-mooneyso we were effectivly going to treat the extra iothread the same18:07
ivvehor cpu_isolation if you wanna let things do whatever, i guess18:07

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!