Tuesday, 2025-02-25

melwittfyi elodilles these ^ are fixes for an not-yet-released regression so it would be best to not make releases on these branches until they are merged00:24
opendevreviewMerged openstack/nova master: libvirt: direct SPICE console object changes  https://review.opendev.org/c/openstack/nova/+/92687600:35
opendevreviewMerged openstack/nova master: libvirt: direct SPICE console database changes  https://review.opendev.org/c/openstack/nova/+/92687701:26
opendevreviewMerged openstack/nova master: libvirt: allow direct SPICE connections to qemu  https://review.opendev.org/c/openstack/nova/+/92484403:23
sean-k-mooney[m]mikal:  ^ congrats03:24
opendevreviewTakashi Kajinami proposed openstack/nova master: Use consistent program name for wsgi scripts and entry points  https://review.opendev.org/c/openstack/nova/+/94260503:43
opendevreviewTakashi Kajinami proposed openstack/nova master: Migrate MEM_ENCRYPTION_CONTEXT from root provider  https://review.opendev.org/c/openstack/nova/+/92181403:48
opendevreviewTakashi Kajinami proposed openstack/nova master: Detect AMD SEV-ES support  https://review.opendev.org/c/openstack/nova/+/92568503:48
opendevreviewTakashi Kajinami proposed openstack/nova master: Add hw_mem_encryption_model image property  https://review.opendev.org/c/openstack/nova/+/92770603:48
opendevreviewTakashi Kajinami proposed openstack/nova master: libvirt: Launch instances with SEV-ES memory encryption  https://review.opendev.org/c/openstack/nova/+/92610603:48
tkajinamI know people are busy these days but I really hope I can get feedback about this series ^^^03:50
tkajinamand https://review.opendev.org/c/openstack/nova/+/84566003:50
tkajinamhttps://review.opendev.org/c/openstack/nova/+/940619 is also easy-win to get rid of deprecation warnings03:51
sshmlbrgsean-k-mooney: Are you around? Is nova_context temporary mutation context manager?05:10
fricklersean-k-mooney: I was talking about the igb change that you referenced before, yes. 0.6.3 was done 2 days after it merged, so it should be included. also 22.04 hwe and 24.04 kernels should be kind of synced?06:29
mikalsean-k-mooney: I saw that, but had to cook dinner so the kids didn't resort to cannibalism. Thanks again for all your help.08:48
mikalsean-k-mooney: now to get the client patches merged I suppose. I wonder if I've missed the deadline for that in epoxy...08:48
opendevreviewribaudr proposed openstack/nova master: Add managed flag to PCI device specification  https://review.opendev.org/c/openstack/nova/+/93764909:09
opendevreviewribaudr proposed openstack/nova master: Update driver to deal with managed flag  https://review.opendev.org/c/openstack/nova/+/93840509:09
sean-k-mooneymikal: client freeze is gerneally the saem as FF11:43
sean-k-mooneyfrickler: the 22.04 hwe kernel is basiclly the kernels form the 3 non lts release until the next lts. 24.04 baseline might be similar but 24.04 hwe will be newer11:45
sean-k-mooneyfrickler: its not critical but i was hoping that it might help with some of the kernel panic we see although that genearly seam to be related to swtiching form the initramfs so it might not actuly be a "kernel" bug so much as an issue with how we are booting11:46
sean-k-mooneyfrickler: i like cirros and dfisk image builder (i know cirros does not use that) but on think i hav ebeen meening to look into is bootc images i.e. bootable iamge build with podman and https://github.com/osbuild/bootc-image-builder fedora-minimal is 48MB i wonder how much bigger that woudl be if i added the kernel via the bootc build process11:57
sean-k-mooneyi got pretty far with my alpine poc a few years ago but never had time to complete it 11:58
sean-k-mooneyfriday is a hack/hussle day technailly at redhat so i might actuly use it to hack on somethign related to cirros or another minimal image11:59
sean-k-mooneythat or ill get distracted and work on feature freeze stuff :)12:00
sean-k-mooneythe normal fedora bootc image is like 900 MB which defaute the goal fo a small test image because there are plent fo cloud image out there that are smaller or the same size12:01
opendevreviewDouglas Viroel proposed openstack/nova master: Add support for showing scheduler_hints in server details  https://review.opendev.org/c/openstack/nova/+/93860412:48
opendevreviewribaudr proposed openstack/nova master: Add managed flag to PCI device specification  https://review.opendev.org/c/openstack/nova/+/93764914:34
opendevreviewribaudr proposed openstack/nova master: Update driver to deal with managed flag  https://review.opendev.org/c/openstack/nova/+/93840514:34
opendevreviewribaudr proposed openstack/nova master: Add managed flag to PCI device specification  https://review.opendev.org/c/openstack/nova/+/93764914:54
opendevreviewribaudr proposed openstack/nova master: Update driver to deal with managed flag  https://review.opendev.org/c/openstack/nova/+/93840514:54
sean-k-mooneyUggla: can you confirm the tags are proply updated on the comptue node tabel too15:25
sean-k-mooneyfor https://review.opendev.org/c/openstack/nova/+/93764915:25
sean-k-mooneyUggla: we do not require it for the manage feature but the tags are includied in the pci_stats column in the ComputeNode table https://github.com/openstack/nova/blob/master/nova/db/main/models.py#L227-L22915:29
sean-k-mooneywe will need that for the live migratable tag15:29
sean-k-mooneyi expect the existing logig to proprly update that without you needing to do anything15:30
sean-k-mooneyfor managed15:30
sean-k-mooneybut it woudl be good to confirm15:30
gibisean-k-mooney: do you mean if the live-migratable flag is removed from the dev_spec then the pci pool containing the matching device should also be updated?15:31
Ugglasean-k-mooney, you mean if this is register in the DB table ? --> https://paste.opendev.org/show/ba4BTb1bDKjCU052R3UP/15:31
gibiI think that is fairly implict as the pools are memory only and the tag is removed with a nova-compute service restart15:31
sean-k-mooneythe schduler does nto use the pci_devices table15:31
sean-k-mooneyit uses the pci_stats form the compute node table15:31
gibiahh15:31
gibithen one more table to look at15:31
sean-k-mooneyso the tag for "live migratable" will be stroed in the pci_stats15:32
gibiI assumed pci stats in memory only and not persisted, but then I was wrong15:32
gibiTIL 15:32
sean-k-mooneygibi: think of pools as placement inventoies15:32
sean-k-mooneythey just have the count and tags instead of traits15:32
sean-k-mooneyya no this is needed for multi cell15:32
sean-k-mooneywe cant pass the statc via the scheduler update 15:33
sean-k-mooneyrpc15:33
sean-k-mooneythe scdhluer need to be able to load them form the cell db when creatign the host state object15:33
sean-k-mooneygibi: we dont need to look at managed in the schduer so this is really only relevnet ot the second series but the behvior shoudld be the same. the pools shoudl be in sync with the config15:35
gibiack15:35
sean-k-mooneyhttps://github.com/openstack/nova/blob/master/nova/pci/stats.py#L66-L7915:36
sean-k-mooneymangage may be something we should add to the ignored tags15:36
sean-k-mooneyi can leave a comment to that effect on the reviews but i just notice the patches have been updated15:38
sean-k-mooneyi have not reviewd the most recent version yet. wehn i saw the paste only had the pci device table in it i was wondering if this had been missed15:38
sean-k-mooneybut i have not looked at the code to confirm15:39
gibisean-k-mooney: I think (weakly) that having extra tags on the device / pool is not an issue as the pool matching logic should be looking at the requested tags from the request side and ignore any extra on the pool side15:39
gibithis is the a response for the ignored tags comment15:40
sean-k-mooneycorrect and the ovo defines the tags as a dict of nullable strings15:40
sean-k-mooneyhttps://github.com/openstack/nova/blob/master/nova/objects/pci_device_pool.py#L3615:40
sean-k-mooneyso its not an object change15:40
sean-k-mooneyhowever we should keep the summery in the pools small in general to keep the memory overhead in the schduler and rpc size down15:41
gibiwait do we send the Pool across the wire? you just said above scheduler loads it from the DB15:42
sean-k-mooneyi think this could be a follow up patch but we likely shoudl filter out managed since we do not have a usecase for it in the schduler currently since managed is not in the alias 15:42
sean-k-mooneyi belive we send it across the wire in a few cases.15:42
sean-k-mooneywe have the schduler resouce view update perodic15:42
sean-k-mooneywhere the compute manger updates the schduler with info about the instance on the host ectra15:43
sean-k-mooneybut its also going to get pulled when we do a hypervior list. which i guess is not over rpc15:43
sean-k-mooneybut directly from the db15:43
gibiyeah hypervisor list only goes to RPC if it wants to get the uptime from the compute15:44
gibianyhow15:44
sean-k-mooneyi think that was zen only?15:44
sean-k-mooneyalso deleteed in newer api versions so im not that worries about that15:44
gibiso for the FF we need to check if pci_stats table is also clean after a tag removal. The ignored_tags thing might wait as it does not seem to break anything15:45
sean-k-mooneyyep15:46
sean-k-mooneyit would only be in the pool if you opted into the feature anyway15:46
sean-k-mooneyfor live migration its imporant that that flag is there so we can select a device that supports it in teh pci passthough filter15:46
gibiI fail to see the pci_stats table in my deployment....15:47
sean-k-mooneyits not a table15:48
sean-k-mooneyits a colum on the compute_node table15:48
gibiaah15:48
gibiOK15:48
sean-k-mooneyso its pulled anytime we pull a compute node object unless we are explcitly lazyloading that15:48
sean-k-mooneyits saved back every time update aviable resocues commits back the updated values15:49
sean-k-mooneyso its updated here https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L1377-L1382 and then its converted into the db format on compute node save by https://github.com/openstack/nova/blob/master/nova/objects/compute_node.py#L321-L32615:57
bauzas#startmeeting nova16:00
opendevmeetMeeting started Tue Feb 25 16:00:40 2025 UTC and is due to finish in 60 minutes.  The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.16:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:00
opendevmeetThe meeting name has been set to 'nova'16:00
gibisean-k-mooney: https://paste.opendev.org/show/bEWhDvmH5NPNozp8V4pU/ confirmed the pci_stats also cleaned16:01
sean-k-mooneygibi: cool i expected it to be. its just it should not be there at all. but we can adress that in a trivial followup16:02
sean-k-mooneyor dicsuss it more after the meeting16:02
bauzas#link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting16:02
elodilleso/16:02
bauzashowdy folks, sorry was late16:02
* bauzas is trampled by many things at same time16:02
sean-k-mooneyo/16:03
bauzaslet's start16:03
bauzas#topic Bugs (stuck/critical) 16:03
masahitoo/16:03
bauzas#info No Critical bug16:03
bauzas#info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster16:03
bauzasany bugs to talk ?16:04
bauzaslooks not16:04
bauzas#topic Gate status 16:05
bauzas#link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs 16:05
bauzas#link https://etherpad.opendev.org/p/nova-ci-failures-minimal16:05
bauzas(I'll leave the next PTL to curate that long list)16:05
bauzas#link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&branch=stable%2F*&branch=master&pipeline=periodic-weekly&skip=0 Nova&Placement periodic jobs status16:05
bauzas#info Please look at the gate failures and file a bug report with the gate-failure tag.16:05
bauzas#info Please try to provide meaningful comment when you recheck16:05
bauzasfor me, the gate is correct16:05
bauzasyet a few rechecks because of the usual suspects (guest panic and ssh timeouts) but nothing new and putting epoxy-3 at risk16:06
sean-k-mooneybauzas: there is perhaps one16:06
Ugglao/16:06
sean-k-mooneyone of the funtional test for vgpu multi type  is failing randomly16:06
bauzashmmm16:07
sean-k-mooneybauzas: i dont have the link but i pingged it in the channel yesterday16:07
bauzasthat may be related to the leaky greenlet16:07
sean-k-mooneyit triggering the greenlet leak detachtion16:07
sean-k-mooneyright it is16:07
bauzasyeah, but that's not new 16:07
sean-k-mooneyso that a bug in the test16:07
fwieselo/16:07
sean-k-mooneywell that somethign that shoudl be fixed as its causing extra rechecks16:07
bauzasso maybe some side effect happened that would increase the failure rate16:07
sean-k-mooneyits not critical but we should not ignore it16:08
bauzasI don't disagree16:08
sean-k-mooneybauzas: if there is an excption in the leaked greenthread16:08
sean-k-mooneyit cn cause other test to fail becuase of that16:08
bauzasI can try to take a look on it, particularly given I have another bugfix patch I'd want to be merged before RC116:08
sean-k-mooneyso it cause hard to diagnose inter test interaction which is why we added the leak detection16:08
sean-k-mooneyack its more an fyi16:09
bauzascool16:09
bauzas#topic Release Planning 16:09
bauzas#link https://releases.openstack.org/epoxy/schedule.html16:09
bauzas#info Nova deadlines are set in the above schedule16:09
bauzas#info 2 days before Feature Freeze16:10
elodillesnote that there are client library release patches open:16:10
elodilleshttps://review.opendev.org/c/openstack/releases/+/94253416:10
elodilleshttps://review.opendev.org/c/openstack/releases/+/94255116:10
elodilles(osc-placement and python-novaclient)16:10
elodillesjust an fyi as we have Epoxy-3 now o:)16:11
sean-k-mooneyso those have the same freeze deadline as nova right16:11
bauzasnoted, I'll review them16:11
sean-k-mooneyi.e. thrusday16:11
elodillesyepp16:11
sean-k-mooneybut we will want to do a release at m3 to test with them for RC116:11
elodilles+116:11
sean-k-mooneywe shoudl not haver anything pending for osc-palcement or novaclient that im aware of16:12
sean-k-mooneyso we can probly do those effectivly now16:12
sean-k-mooneyon clients16:12
sean-k-mooneywe have some new api versions this cycle and im not sure we will have osc suprot for those in time16:13
sean-k-mooneyso they may get enabled next cycle16:13
sean-k-mooneybut there isnt really anything we can do there at this point if the sdk supprot is not already merged16:13
sean-k-mooneyelodilles: am i correct in saying the sdk is subject to the non clinet code freeze so we should not expect to merge supprot for spice direct or image property shod api microversion between now and FF16:14
elodillessean-k-mooney: if i'm not mistaken sdk already merged it's final release patch recently16:15
sean-k-mooneyack that what i was expecting16:15
elodilleswell,16:15
elodillesit's still open,16:16
elodilleswaiting for a 2nd +2: https://review.opendev.org/c/openstack/releases/+/94185916:16
elodillesfrom release team16:16
sean-k-mooneyi think we are missing a finaly release for os-traits and perhaps os-resouce classes too by the way16:17
elodillesthose are 'independent' projects, hence not picked up by release tools16:17
sean-k-mooneywe have not merged any content since the last release we did for either16:17
sean-k-mooneyah ok16:17
elodillesbut wasn't there os-traits release recently?16:17
sean-k-mooneyyes but we had traits we wanted to add and have anouther release 3 days after that happend:)16:18
sean-k-mooneythe os-traits patch is still pending a second +216:18
elodillessean-k-mooney: this is the content of SDK release (if it doesn't change anymore): https://zuul.opendev.org/t/openstack/build/24cc79c0e8e84d7d853e679e4e928585/log/tox/list-changes/list-changes-results.log#918-94716:18
opendevreviewJay Faulkner proposed openstack/nova master: PoC: Allow unversioned-notify specific transport url  https://review.opendev.org/c/openstack/nova/+/94271016:19
sean-k-mooneyok we can likely move on and revisit in open dicuss if there is more to bring up16:19
elodilles+116:19
bauzascan we move on ?16:21
elodillesyepp16:21
bauzascool16:23
bauzas#topic Review priorities 16:23
bauzas#link https://etherpad.opendev.org/p/nova-2025.1-status16:23
bauzasnothing to tell about, I'm doing hard reviews16:25
bauzasanything else ?16:25
bauzaslooks not16:26
opendevreviewDoug Goldstein proposed openstack/nova master: ironic: fix logging of validation errors  https://review.opendev.org/c/openstack/nova/+/94201916:26
bauzas#topic PTG planning 16:26
bauzas#info Next PTG will be held on Apr 7-1116:26
bauzasusual reminder, please fill the agenda !16:26
bauzas#link https://etherpad.opendev.org/p/nova-2025.2-ptg16:26
bauzas#topic Stable Branches 16:27
bauzaselodilles: your turn16:28
elodillesACK16:28
elodillesactually, same as last week:16:28
elodilles#info stable gates seem to be healthy16:28
elodilles#info stable/2023.2 release patch: https://review.opendev.org/c/openstack/releases/+/941420 (stable/2023.2 (bobcat) is going to transition to EOL in ~2 months)16:28
elodilles#info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci16:28
elodillesthat's all16:28
bauzascool16:31
bauzas#topic vmwareapi 3rd-party CI efforts Highlights 16:31
bauzasfwiesel: around ?16:31
fwieselNo updates from my side. I am a bit under the weather.16:31
bauzasditto here16:33
bauzasI understand you16:33
bauzas#topic Open discussion 16:35
bauzasI have one item16:35
bauzaskudos to Uggla for being our next PTL \o/16:36
Ugglathx16:36
gibicongrats16:36
gibiand thanks bauzas for the long service as PTL16:36
fwieselCongrats16:36
elodillesyepp ++ \o/16:36
* Uggla hoping bauzas will still be around to help me jumping in that role. ;)16:37
bauzasI will !16:38
masahitocongrats and thank you16:38
bauzasanyway, moving to the questions16:38
bauzas(hertrste) Nova Cloud Hypervisor support 16:39
hertrsteHi o/16:39
hertrsteWe would like to add support for the Cloud Hypervisor VMM to openstack Nova16:39
hertrsteAs we have not contributed anything yet, we would like some guidance how to approach that16:40
sean-k-mooney this yes https://github.com/cloud-hypervisor/cloud-hypervisor16:40
hertrsteAs you can see in the meeting notes, we have a proof of concept 16:40
hertrsteexactly16:40
sean-k-mooneyi breifly looked at that a few months ago out of interest when i was playing with rust16:41
hertrsteWe also have a proof of concept adding some basic support for that VMM: https://github.com/openstack/nova/commit/617ac2f655492d1b84b2d924412ac7063d23111016:41
sean-k-mooneyit has an interesting feature set16:41
gibiI think the next step there is to have PTG topic proposed for this16:41
sean-k-mooney hertrste  our main concerns would be likely testing, and building out a minimal supportrable feature set16:42
bauzasyeah, looks to me a good PTG session16:42
sean-k-mooneythat would invovle defining a spec (if the propsal to add a new driver was green lit)16:42
bauzashertrste: can you attend it ?16:42
dansmithI'd also be interested in knowing how widely it is used/deployed16:42
sean-k-mooneyto descibe the expecations16:42
dansmithand also, why it's not just a libvirt driver :)16:43
sean-k-mooneywell i dont neesislay think we shoudl say all linux hyperviors shoudl be behind libvirt16:43
hertrsteI can very much attend a PTG. What would I need to prepare for that? When would that meeting take place?16:43
sean-k-mooneyit has its pros and cons16:43
dansmithsean-k-mooney: no, doesn't have to be, but there's a lot of stuff to re-implement in nova if it's not, and so I'd expect there to be a good reason for it16:44
gibihertrste: https://openinfra.org/ptg/16:44
bauzashertrste: see the above discussion about PTG 16:44
Ugglahertrste,  Apr 7-1116:45
sean-k-mooneyhertrste: i think the main things to prepare is an elevator pitch explaining why an operator may want ot use this16:45
sean-k-mooneywwhat usecases and target workloads woudl it enable16:45
tpressurelibvirt has a poor hypervisor abstraction. If we would go the libvirt route, we would effectively have to maintain two components instead of only one. You cannot simply map qemu calls to cloud hypervisor16:46
dansmithsean-k-mooney: especially since it appearently already exist: https://libvirt.org/drvch.html16:46
sean-k-mooneyand beyond that how you plan to test and develop supproted for it on an ongoing basis16:46
sean-k-mooneytpressure: well we dont generate qemu calls today16:46
sean-k-mooneynova generate a semi hypervior indepent xml16:47
sean-k-mooneywe "supprot" libvirt with lxc, qemu and i think openvz16:47
sean-k-mooneyalthoug everything excpt for qemu is basiclly not tested or maintaiend anymore16:47
sean-k-mooneytpressure: hertrste  based on https://libvirt.org/drvch.html provied by dan there si already some supprot for cloud-hypervior in libvirt16:48
hertrsteyeah we know of that support16:48
sean-k-mooneyso the question woudl be what does a full virt driver provide that cant be done vai that16:48
dansmithand more than that, why would it be worth maintaining that *and* a separate full nova driver16:49
dansmithlike, what will never be possible via libvirt that would be if we have a whole separate implementation in nova16:49
hertrstewe decided not to use it because we felt the overhead of dealing with the existing 14k LoC for the libvirt backend in Nova was not worth. at least for a proof of concept16:49
dansmithbecause libvirt brings all kinds of things like network and storage abstraction that would have to be written from scratch in a nova driver16:49
hertrsteFurther, libvirt only has very basic support for cloud hypervisor. so we basically would need to add features in 2 complex code bases16:50
sean-k-mooneythe main concern i would have iwth the current poc16:50
sean-k-mooneyis its directly invoking a command line client correct16:50
dansmithhertrste: that's only true if you're talking about a feature that isn't supported at all by libvirt, which is honestly going to be a hard sell in nova anyway16:50
sean-k-mooney which means you are commiting to providign a forward compatiable stable cli fro nova to use16:51
bauzasfolks, because we have another item to discuss, can we stop here ? 16:51
dansmithsean-k-mooney: and hopefully there is some way to not kill those instances when nova restarts.. I hope it doesn't make nova responsible for being the init system for those binaries...16:51
sean-k-mooneysure we can move on16:51
dansmithbauzas: yes, I have to run anyway.. but a preview of my concerns for PTG :)16:52
sean-k-mooneydansmith: ack16:52
hertrstethanks for the feedback16:52
bauzashertrste: ping me if you have any questions about the PTG, I'll try to answer your concerns16:52
bauzasmoving on then16:52
bauzas (mzhang741) Add Burst Length Support to Cinder QoS 16:52
bauzasis mzhang741 here ?16:52
MengyangZhang[m]yes16:53
bauzas https://review.opendev.org/c/openstack/nova-specs/+/93265316:53
bauzasseems to me a design question16:53
bauzascould we just do this in the gerrit change review ?16:53
bauzasdo we need a quorum consensus ?16:54
MengyangZhang[m]besides that min version check question, also need review and approval of the spec to move forward16:55
bauzasMengyangZhang[m]: that's our usual review cycle16:56
bauzasbut for the moment, even 2025.2 work hasn't started16:56
bauzasso please understand that people have other priorities for now16:56
bauzasMengyangZhang[m]: the best if you want is to have a cross-project discussion with the cinder folks at the PTG16:57
sean-k-mooneybauzas: context for this16:57
bauzasthat would I guess answer most of the design questions, and it would be quick16:57
MengyangZhang[m]understood, meanwhile can I have some clarity on that design question? I may shift my focus to other projects in my company and won't be able to follow this until q216:58
sean-k-mooneyi was orginally asking that we have  a min version ceck to know that the compute node can supprot the new frontend qos option16:58
sean-k-mooneyit turns out that cinder allows you to update the qos on a volume type16:58
bauzassean-k-mooney: that's the usual upgrade pattern yeah16:58
sean-k-mooneyand it will take effect to  all volumes of that type16:58
sean-k-mooneyon the next move op16:58
sean-k-mooneyor when we next update the attachment16:58
bauzasso even old computes would see it ?16:59
sean-k-mooneyso cinder is not caching it liek we do with the falvor/image properties when the volume is created16:59
sean-k-mooneyyep16:59
sean-k-mooneyso this is a pre exisitng upgrade problem16:59
bauzasthat's an harder upgrade pattern to solve16:59
bauzasyeah, sounds16:59
sean-k-mooneyso i dont think we can actully really protect agaisnt this in nova16:59
bauzaslike, someone has to do a pre-upgrade flight16:59
bauzaswe could say 'unsupported until all your computes are upgraded'17:00
sean-k-mooneyanyway we shoudl dicuss more with the cinder folks17:00
sean-k-mooneybut we cant just enforce "not supported until all upgraded" in our code just in docs17:00
bauzasis there any API impact? tbh I haven't reviewed the spec17:00
bauzashah17:00
bauzassounds to me then a perfect cinder-nova PTG discussion17:01
bauzasMengyangZhang[m]: could you join the PTG ?17:01
bauzasanyway, we're on time17:01
bauzasthanks all17:01
bauzas#endmeeting17:01
opendevmeetMeeting ended Tue Feb 25 17:01:39 2025 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)17:01
opendevmeetMinutes:        https://meetings.opendev.org/meetings/nova/2025/nova.2025-02-25-16.00.html17:01
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-02-25-16.00.txt17:01
opendevmeetLog:            https://meetings.opendev.org/meetings/nova/2025/nova.2025-02-25-16.00.log.html17:01
MengyangZhang[m]sure, do i need to register for the event? You mean the one from April 7-11, right? Let me know what I need to do17:01
MengyangZhang[m]sorry would be my first time joining17:02
sean-k-mooneybauzas: no api impact on our side or cinders becuase they dont version this part of the api17:02
sean-k-mooneyalthogh that coudl depend on the ptg dicussion17:03
bauzassean-k-mooney: I definitely need to review the spec then17:03
sean-k-mooneyone topic MengyangZhang[m] was interested in was a way to refesh the qos on a volume live17:03
fwieselThanks everyone17:03
sean-k-mooneythat woul likely need a new instance action17:03
bauzaswow17:03
sean-k-mooneybut i dont think that is in the spec17:03
bauzas'taint my instance'17:04
sean-k-mooneybauzas: libvirt supprot updatign them17:04
sean-k-mooneywe just dont 17:04
bauzaslibvirt can do many things we don't17:04
MengyangZhang[m]it's a separate bp and doesn;t have a spec yet17:04
bauzasthis doesn't mean that we should wrap all libvirt things 17:04
sean-k-mooneybauzas: its basically asking us to sync nova state with cidner state since it allows it to change without our say so17:04
bauzaswe're a cloud API, libvirt is an hypervisor17:04
bauzasdiffreent usecases17:05
sean-k-mooneybauzas: today it gets updated on live migration...17:05
sean-k-mooneyso you update it in cinder and the new atachment used for live migation will get the new qos...17:05
sean-k-mooneynova does not offically supprot that17:06
sean-k-mooneyi personally consier that a but but its apprely what happens today17:06
bauzaswe had events for cross-project communication, right?17:06
sean-k-mooneywe do it does nto use that17:06
sean-k-mooneyits because we only use those event on the volume17:06
sean-k-mooneywhere as they are chging the qos on teh voluem type17:06
bauzasanyway, looks we definitely need to design it at the PTG17:06
sean-k-mooneybasiclly they are updating there version fo a flavor and applying it to all instnaces 17:07
bauzasand I need to leave now, python meeting downtown17:07
sean-k-mooneyo/17:07
MengyangZhang[m]thanks for all the discussion. sounds like we will continue this in PTG, let me know how to register it coz I think it already passed the registration deadline of Feb 21, no?17:09
MengyangZhang[m]Oh i think i managed to register on openinfra site17:12
opendevreviewStefan Hoffmann proposed openstack/os-vif master: [ovs] Add method to get external_ids from Interface  https://review.opendev.org/c/openstack/os-vif/+/94271517:16
vsaienkohello nova team, please add to your review queue. Fixes non working ironic serial console https://review.opendev.org/c/openstack/nova/+/94257517:35
vsaienkoalready has +1 from Ironic folks17:35
JayFand I think we should be able to backport it given the osdk fix is backporting, too17:39
opendevreviewDouglas Viroel proposed openstack/nova master: Add support for showing scheduler_hints in server details  https://review.opendev.org/c/openstack/nova/+/93860419:07
mikalMorning19:09
opendevreviewMerged openstack/nova master: Per-Property ImageMetaPropsWeigher  https://review.opendev.org/c/openstack/nova/+/94160119:16
opendevreviewDouglas Viroel proposed openstack/nova master: DNM - Testing microversion 2.100 changes  https://review.opendev.org/c/openstack/nova/+/94272820:07
opendevreviewAlan Bishop proposed openstack/nova master: Show swap_progress in attachment details  https://review.opendev.org/c/openstack/nova/+/94147621:25

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