melwitt | fyi 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 merged | 00:24 |
---|---|---|
opendevreview | Merged openstack/nova master: libvirt: direct SPICE console object changes https://review.opendev.org/c/openstack/nova/+/926876 | 00:35 |
opendevreview | Merged openstack/nova master: libvirt: direct SPICE console database changes https://review.opendev.org/c/openstack/nova/+/926877 | 01:26 |
opendevreview | Merged openstack/nova master: libvirt: allow direct SPICE connections to qemu https://review.opendev.org/c/openstack/nova/+/924844 | 03:23 |
sean-k-mooney[m] | mikal: ^ congrats | 03:24 |
opendevreview | Takashi Kajinami proposed openstack/nova master: Use consistent program name for wsgi scripts and entry points https://review.opendev.org/c/openstack/nova/+/942605 | 03:43 |
opendevreview | Takashi Kajinami proposed openstack/nova master: Migrate MEM_ENCRYPTION_CONTEXT from root provider https://review.opendev.org/c/openstack/nova/+/921814 | 03:48 |
opendevreview | Takashi Kajinami proposed openstack/nova master: Detect AMD SEV-ES support https://review.opendev.org/c/openstack/nova/+/925685 | 03:48 |
opendevreview | Takashi Kajinami proposed openstack/nova master: Add hw_mem_encryption_model image property https://review.opendev.org/c/openstack/nova/+/927706 | 03:48 |
opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Launch instances with SEV-ES memory encryption https://review.opendev.org/c/openstack/nova/+/926106 | 03:48 |
tkajinam | I know people are busy these days but I really hope I can get feedback about this series ^^^ | 03:50 |
tkajinam | and https://review.opendev.org/c/openstack/nova/+/845660 | 03:50 |
tkajinam | https://review.opendev.org/c/openstack/nova/+/940619 is also easy-win to get rid of deprecation warnings | 03:51 |
sshmlbrg | sean-k-mooney: Are you around? Is nova_context temporary mutation context manager? | 05:10 |
frickler | sean-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 |
mikal | sean-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 |
mikal | sean-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 |
opendevreview | ribaudr proposed openstack/nova master: Add managed flag to PCI device specification https://review.opendev.org/c/openstack/nova/+/937649 | 09:09 |
opendevreview | ribaudr proposed openstack/nova master: Update driver to deal with managed flag https://review.opendev.org/c/openstack/nova/+/938405 | 09:09 |
sean-k-mooney | mikal: client freeze is gerneally the saem as FF | 11:43 |
sean-k-mooney | frickler: 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 newer | 11:45 |
sean-k-mooney | frickler: 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 booting | 11:46 |
sean-k-mooney | frickler: 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 process | 11:57 |
sean-k-mooney | i got pretty far with my alpine poc a few years ago but never had time to complete it | 11:58 |
sean-k-mooney | friday is a hack/hussle day technailly at redhat so i might actuly use it to hack on somethign related to cirros or another minimal image | 11:59 |
sean-k-mooney | that or ill get distracted and work on feature freeze stuff :) | 12:00 |
sean-k-mooney | the 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 size | 12:01 |
opendevreview | Douglas Viroel proposed openstack/nova master: Add support for showing scheduler_hints in server details https://review.opendev.org/c/openstack/nova/+/938604 | 12:48 |
opendevreview | ribaudr proposed openstack/nova master: Add managed flag to PCI device specification https://review.opendev.org/c/openstack/nova/+/937649 | 14:34 |
opendevreview | ribaudr proposed openstack/nova master: Update driver to deal with managed flag https://review.opendev.org/c/openstack/nova/+/938405 | 14:34 |
opendevreview | ribaudr proposed openstack/nova master: Add managed flag to PCI device specification https://review.opendev.org/c/openstack/nova/+/937649 | 14:54 |
opendevreview | ribaudr proposed openstack/nova master: Update driver to deal with managed flag https://review.opendev.org/c/openstack/nova/+/938405 | 14:54 |
sean-k-mooney | Uggla: can you confirm the tags are proply updated on the comptue node tabel too | 15:25 |
sean-k-mooney | for https://review.opendev.org/c/openstack/nova/+/937649 | 15:25 |
sean-k-mooney | Uggla: 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-L229 | 15:29 |
sean-k-mooney | we will need that for the live migratable tag | 15:29 |
sean-k-mooney | i expect the existing logig to proprly update that without you needing to do anything | 15:30 |
sean-k-mooney | for managed | 15:30 |
sean-k-mooney | but it woudl be good to confirm | 15:30 |
gibi | sean-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 |
Uggla | sean-k-mooney, you mean if this is register in the DB table ? --> https://paste.opendev.org/show/ba4BTb1bDKjCU052R3UP/ | 15:31 |
gibi | I think that is fairly implict as the pools are memory only and the tag is removed with a nova-compute service restart | 15:31 |
sean-k-mooney | the schduler does nto use the pci_devices table | 15:31 |
sean-k-mooney | it uses the pci_stats form the compute node table | 15:31 |
gibi | ahh | 15:31 |
gibi | then one more table to look at | 15:31 |
sean-k-mooney | so the tag for "live migratable" will be stroed in the pci_stats | 15:32 |
gibi | I assumed pci stats in memory only and not persisted, but then I was wrong | 15:32 |
gibi | TIL | 15:32 |
sean-k-mooney | gibi: think of pools as placement inventoies | 15:32 |
sean-k-mooney | they just have the count and tags instead of traits | 15:32 |
sean-k-mooney | ya no this is needed for multi cell | 15:32 |
sean-k-mooney | we cant pass the statc via the scheduler update | 15:33 |
sean-k-mooney | rpc | 15:33 |
sean-k-mooney | the scdhluer need to be able to load them form the cell db when creatign the host state object | 15:33 |
sean-k-mooney | gibi: 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 config | 15:35 |
gibi | ack | 15:35 |
sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/pci/stats.py#L66-L79 | 15:36 |
sean-k-mooney | mangage may be something we should add to the ignored tags | 15:36 |
sean-k-mooney | i can leave a comment to that effect on the reviews but i just notice the patches have been updated | 15:38 |
sean-k-mooney | i 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 missed | 15:38 |
sean-k-mooney | but i have not looked at the code to confirm | 15:39 |
gibi | sean-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 side | 15:39 |
gibi | this is the a response for the ignored tags comment | 15:40 |
sean-k-mooney | correct and the ovo defines the tags as a dict of nullable strings | 15:40 |
sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/objects/pci_device_pool.py#L36 | 15:40 |
sean-k-mooney | so its not an object change | 15:40 |
sean-k-mooney | however we should keep the summery in the pools small in general to keep the memory overhead in the schduler and rpc size down | 15:41 |
gibi | wait do we send the Pool across the wire? you just said above scheduler loads it from the DB | 15:42 |
sean-k-mooney | i 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-mooney | i belive we send it across the wire in a few cases. | 15:42 |
sean-k-mooney | we have the schduler resouce view update perodic | 15:42 |
sean-k-mooney | where the compute manger updates the schduler with info about the instance on the host ectra | 15:43 |
sean-k-mooney | but its also going to get pulled when we do a hypervior list. which i guess is not over rpc | 15:43 |
sean-k-mooney | but directly from the db | 15:43 |
gibi | yeah hypervisor list only goes to RPC if it wants to get the uptime from the compute | 15:44 |
gibi | anyhow | 15:44 |
sean-k-mooney | i think that was zen only? | 15:44 |
sean-k-mooney | also deleteed in newer api versions so im not that worries about that | 15:44 |
gibi | so 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 anything | 15:45 |
sean-k-mooney | yep | 15:46 |
sean-k-mooney | it would only be in the pool if you opted into the feature anyway | 15:46 |
sean-k-mooney | for live migration its imporant that that flag is there so we can select a device that supports it in teh pci passthough filter | 15:46 |
gibi | I fail to see the pci_stats table in my deployment.... | 15:47 |
sean-k-mooney | its not a table | 15:48 |
sean-k-mooney | its a colum on the compute_node table | 15:48 |
gibi | aah | 15:48 |
gibi | OK | 15:48 |
sean-k-mooney | so its pulled anytime we pull a compute node object unless we are explcitly lazyloading that | 15:48 |
sean-k-mooney | its saved back every time update aviable resocues commits back the updated values | 15:49 |
sean-k-mooney | so 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-L326 | 15:57 |
bauzas | #startmeeting nova | 16:00 |
opendevmeet | Meeting 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 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
opendevmeet | The meeting name has been set to 'nova' | 16:00 |
gibi | sean-k-mooney: https://paste.opendev.org/show/bEWhDvmH5NPNozp8V4pU/ confirmed the pci_stats also cleaned | 16:01 |
sean-k-mooney | gibi: cool i expected it to be. its just it should not be there at all. but we can adress that in a trivial followup | 16:02 |
sean-k-mooney | or dicsuss it more after the meeting | 16:02 |
bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:02 |
elodilles | o/ | 16:02 |
bauzas | howdy folks, sorry was late | 16:02 |
* bauzas is trampled by many things at same time | 16:02 | |
sean-k-mooney | o/ | 16:03 |
bauzas | let's start | 16:03 |
bauzas | #topic Bugs (stuck/critical) | 16:03 |
masahito | o/ | 16:03 |
bauzas | #info No Critical bug | 16:03 |
bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:03 |
bauzas | any bugs to talk ? | 16:04 |
bauzas | looks not | 16: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-minimal | 16: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 status | 16: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 recheck | 16:05 |
bauzas | for me, the gate is correct | 16:05 |
bauzas | yet a few rechecks because of the usual suspects (guest panic and ssh timeouts) but nothing new and putting epoxy-3 at risk | 16:06 |
sean-k-mooney | bauzas: there is perhaps one | 16:06 |
Uggla | o/ | 16:06 |
sean-k-mooney | one of the funtional test for vgpu multi type is failing randomly | 16:06 |
bauzas | hmmm | 16:07 |
sean-k-mooney | bauzas: i dont have the link but i pingged it in the channel yesterday | 16:07 |
bauzas | that may be related to the leaky greenlet | 16:07 |
sean-k-mooney | it triggering the greenlet leak detachtion | 16:07 |
sean-k-mooney | right it is | 16:07 |
bauzas | yeah, but that's not new | 16:07 |
sean-k-mooney | so that a bug in the test | 16:07 |
fwiesel | o/ | 16:07 |
sean-k-mooney | well that somethign that shoudl be fixed as its causing extra rechecks | 16:07 |
bauzas | so maybe some side effect happened that would increase the failure rate | 16:07 |
sean-k-mooney | its not critical but we should not ignore it | 16:08 |
bauzas | I don't disagree | 16:08 |
sean-k-mooney | bauzas: if there is an excption in the leaked greenthread | 16:08 |
sean-k-mooney | it cn cause other test to fail becuase of that | 16:08 |
bauzas | I can try to take a look on it, particularly given I have another bugfix patch I'd want to be merged before RC1 | 16:08 |
sean-k-mooney | so it cause hard to diagnose inter test interaction which is why we added the leak detection | 16:08 |
sean-k-mooney | ack its more an fyi | 16:09 |
bauzas | cool | 16:09 |
bauzas | #topic Release Planning | 16:09 |
bauzas | #link https://releases.openstack.org/epoxy/schedule.html | 16:09 |
bauzas | #info Nova deadlines are set in the above schedule | 16:09 |
bauzas | #info 2 days before Feature Freeze | 16:10 |
elodilles | note that there are client library release patches open: | 16:10 |
elodilles | https://review.opendev.org/c/openstack/releases/+/942534 | 16:10 |
elodilles | https://review.opendev.org/c/openstack/releases/+/942551 | 16:10 |
elodilles | (osc-placement and python-novaclient) | 16:10 |
elodilles | just an fyi as we have Epoxy-3 now o:) | 16:11 |
sean-k-mooney | so those have the same freeze deadline as nova right | 16:11 |
bauzas | noted, I'll review them | 16:11 |
sean-k-mooney | i.e. thrusday | 16:11 |
elodilles | yepp | 16:11 |
sean-k-mooney | but we will want to do a release at m3 to test with them for RC1 | 16:11 |
elodilles | +1 | 16:11 |
sean-k-mooney | we shoudl not haver anything pending for osc-palcement or novaclient that im aware of | 16:12 |
sean-k-mooney | so we can probly do those effectivly now | 16:12 |
sean-k-mooney | on clients | 16:12 |
sean-k-mooney | we have some new api versions this cycle and im not sure we will have osc suprot for those in time | 16:13 |
sean-k-mooney | so they may get enabled next cycle | 16:13 |
sean-k-mooney | but there isnt really anything we can do there at this point if the sdk supprot is not already merged | 16:13 |
sean-k-mooney | elodilles: 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 FF | 16:14 |
elodilles | sean-k-mooney: if i'm not mistaken sdk already merged it's final release patch recently | 16:15 |
sean-k-mooney | ack that what i was expecting | 16:15 |
elodilles | well, | 16:15 |
elodilles | it's still open, | 16:16 |
elodilles | waiting for a 2nd +2: https://review.opendev.org/c/openstack/releases/+/941859 | 16:16 |
elodilles | from release team | 16:16 |
sean-k-mooney | i think we are missing a finaly release for os-traits and perhaps os-resouce classes too by the way | 16:17 |
elodilles | those are 'independent' projects, hence not picked up by release tools | 16:17 |
sean-k-mooney | we have not merged any content since the last release we did for either | 16:17 |
sean-k-mooney | ah ok | 16:17 |
elodilles | but wasn't there os-traits release recently? | 16:17 |
sean-k-mooney | yes but we had traits we wanted to add and have anouther release 3 days after that happend:) | 16:18 |
sean-k-mooney | the os-traits patch is still pending a second +2 | 16:18 |
elodilles | sean-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-947 | 16:18 |
opendevreview | Jay Faulkner proposed openstack/nova master: PoC: Allow unversioned-notify specific transport url https://review.opendev.org/c/openstack/nova/+/942710 | 16:19 |
sean-k-mooney | ok we can likely move on and revisit in open dicuss if there is more to bring up | 16:19 |
elodilles | +1 | 16:19 |
bauzas | can we move on ? | 16:21 |
elodilles | yepp | 16:21 |
bauzas | cool | 16:23 |
bauzas | #topic Review priorities | 16:23 |
bauzas | #link https://etherpad.opendev.org/p/nova-2025.1-status | 16:23 |
bauzas | nothing to tell about, I'm doing hard reviews | 16:25 |
bauzas | anything else ? | 16:25 |
bauzas | looks not | 16:26 |
opendevreview | Doug Goldstein proposed openstack/nova master: ironic: fix logging of validation errors https://review.opendev.org/c/openstack/nova/+/942019 | 16:26 |
bauzas | #topic PTG planning | 16:26 |
bauzas | #info Next PTG will be held on Apr 7-11 | 16:26 |
bauzas | usual reminder, please fill the agenda ! | 16:26 |
bauzas | #link https://etherpad.opendev.org/p/nova-2025.2-ptg | 16:26 |
bauzas | #topic Stable Branches | 16:27 |
bauzas | elodilles: your turn | 16:28 |
elodilles | ACK | 16:28 |
elodilles | actually, same as last week: | 16:28 |
elodilles | #info stable gates seem to be healthy | 16: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-ci | 16:28 |
elodilles | that's all | 16:28 |
bauzas | cool | 16:31 |
bauzas | #topic vmwareapi 3rd-party CI efforts Highlights | 16:31 |
bauzas | fwiesel: around ? | 16:31 |
fwiesel | No updates from my side. I am a bit under the weather. | 16:31 |
bauzas | ditto here | 16:33 |
bauzas | I understand you | 16:33 |
bauzas | #topic Open discussion | 16:35 |
bauzas | I have one item | 16:35 |
bauzas | kudos to Uggla for being our next PTL \o/ | 16:36 |
Uggla | thx | 16:36 |
gibi | congrats | 16:36 |
gibi | and thanks bauzas for the long service as PTL | 16:36 |
fwiesel | Congrats | 16:36 |
elodilles | yepp ++ \o/ | 16:36 |
* Uggla hoping bauzas will still be around to help me jumping in that role. ;) | 16:37 | |
bauzas | I will ! | 16:38 |
masahito | congrats and thank you | 16:38 |
bauzas | anyway, moving to the questions | 16:38 |
bauzas | (hertrste) Nova Cloud Hypervisor support | 16:39 |
hertrste | Hi o/ | 16:39 |
hertrste | We would like to add support for the Cloud Hypervisor VMM to openstack Nova | 16:39 |
hertrste | As we have not contributed anything yet, we would like some guidance how to approach that | 16:40 |
sean-k-mooney | this yes https://github.com/cloud-hypervisor/cloud-hypervisor | 16:40 |
hertrste | As you can see in the meeting notes, we have a proof of concept | 16:40 |
hertrste | exactly | 16:40 |
sean-k-mooney | i breifly looked at that a few months ago out of interest when i was playing with rust | 16:41 |
hertrste | We also have a proof of concept adding some basic support for that VMM: https://github.com/openstack/nova/commit/617ac2f655492d1b84b2d924412ac7063d231110 | 16:41 |
sean-k-mooney | it has an interesting feature set | 16:41 |
gibi | I think the next step there is to have PTG topic proposed for this | 16:41 |
sean-k-mooney | hertrste our main concerns would be likely testing, and building out a minimal supportrable feature set | 16:42 |
bauzas | yeah, looks to me a good PTG session | 16:42 |
sean-k-mooney | that would invovle defining a spec (if the propsal to add a new driver was green lit) | 16:42 |
bauzas | hertrste: can you attend it ? | 16:42 |
dansmith | I'd also be interested in knowing how widely it is used/deployed | 16:42 |
sean-k-mooney | to descibe the expecations | 16:42 |
dansmith | and also, why it's not just a libvirt driver :) | 16:43 |
sean-k-mooney | well i dont neesislay think we shoudl say all linux hyperviors shoudl be behind libvirt | 16:43 |
hertrste | I can very much attend a PTG. What would I need to prepare for that? When would that meeting take place? | 16:43 |
sean-k-mooney | it has its pros and cons | 16:43 |
dansmith | sean-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 it | 16:44 |
gibi | hertrste: https://openinfra.org/ptg/ | 16:44 |
bauzas | hertrste: see the above discussion about PTG | 16:44 |
Uggla | hertrste, Apr 7-11 | 16:45 |
sean-k-mooney | hertrste: i think the main things to prepare is an elevator pitch explaining why an operator may want ot use this | 16:45 |
sean-k-mooney | wwhat usecases and target workloads woudl it enable | 16:45 |
tpressure | libvirt 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 hypervisor | 16:46 |
dansmith | sean-k-mooney: especially since it appearently already exist: https://libvirt.org/drvch.html | 16:46 |
sean-k-mooney | and beyond that how you plan to test and develop supproted for it on an ongoing basis | 16:46 |
sean-k-mooney | tpressure: well we dont generate qemu calls today | 16:46 |
sean-k-mooney | nova generate a semi hypervior indepent xml | 16:47 |
sean-k-mooney | we "supprot" libvirt with lxc, qemu and i think openvz | 16:47 |
sean-k-mooney | althoug everything excpt for qemu is basiclly not tested or maintaiend anymore | 16:47 |
sean-k-mooney | tpressure: hertrste based on https://libvirt.org/drvch.html provied by dan there si already some supprot for cloud-hypervior in libvirt | 16:48 |
hertrste | yeah we know of that support | 16:48 |
sean-k-mooney | so the question woudl be what does a full virt driver provide that cant be done vai that | 16:48 |
dansmith | and more than that, why would it be worth maintaining that *and* a separate full nova driver | 16:49 |
dansmith | like, what will never be possible via libvirt that would be if we have a whole separate implementation in nova | 16:49 |
hertrste | we 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 concept | 16:49 |
dansmith | because libvirt brings all kinds of things like network and storage abstraction that would have to be written from scratch in a nova driver | 16:49 |
hertrste | Further, libvirt only has very basic support for cloud hypervisor. so we basically would need to add features in 2 complex code bases | 16:50 |
sean-k-mooney | the main concern i would have iwth the current poc | 16:50 |
sean-k-mooney | is its directly invoking a command line client correct | 16:50 |
dansmith | hertrste: 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 anyway | 16:50 |
sean-k-mooney | which means you are commiting to providign a forward compatiable stable cli fro nova to use | 16:51 |
bauzas | folks, because we have another item to discuss, can we stop here ? | 16:51 |
dansmith | sean-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-mooney | sure we can move on | 16:51 |
dansmith | bauzas: yes, I have to run anyway.. but a preview of my concerns for PTG :) | 16:52 |
sean-k-mooney | dansmith: ack | 16:52 |
hertrste | thanks for the feedback | 16:52 |
bauzas | hertrste: ping me if you have any questions about the PTG, I'll try to answer your concerns | 16:52 |
bauzas | moving on then | 16:52 |
bauzas | (mzhang741) Add Burst Length Support to Cinder QoS | 16:52 |
bauzas | is mzhang741 here ? | 16:52 |
MengyangZhang[m] | yes | 16:53 |
bauzas | https://review.opendev.org/c/openstack/nova-specs/+/932653 | 16:53 |
bauzas | seems to me a design question | 16:53 |
bauzas | could we just do this in the gerrit change review ? | 16:53 |
bauzas | do 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 forward | 16:55 |
bauzas | MengyangZhang[m]: that's our usual review cycle | 16:56 |
bauzas | but for the moment, even 2025.2 work hasn't started | 16:56 |
bauzas | so please understand that people have other priorities for now | 16:56 |
bauzas | MengyangZhang[m]: the best if you want is to have a cross-project discussion with the cinder folks at the PTG | 16:57 |
sean-k-mooney | bauzas: context for this | 16:57 |
bauzas | that would I guess answer most of the design questions, and it would be quick | 16: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 q2 | 16:58 |
sean-k-mooney | i was orginally asking that we have a min version ceck to know that the compute node can supprot the new frontend qos option | 16:58 |
sean-k-mooney | it turns out that cinder allows you to update the qos on a volume type | 16:58 |
bauzas | sean-k-mooney: that's the usual upgrade pattern yeah | 16:58 |
sean-k-mooney | and it will take effect to all volumes of that type | 16:58 |
sean-k-mooney | on the next move op | 16:58 |
sean-k-mooney | or when we next update the attachment | 16:58 |
bauzas | so even old computes would see it ? | 16:59 |
sean-k-mooney | so cinder is not caching it liek we do with the falvor/image properties when the volume is created | 16:59 |
sean-k-mooney | yep | 16:59 |
sean-k-mooney | so this is a pre exisitng upgrade problem | 16:59 |
bauzas | that's an harder upgrade pattern to solve | 16:59 |
bauzas | yeah, sounds | 16:59 |
sean-k-mooney | so i dont think we can actully really protect agaisnt this in nova | 16:59 |
bauzas | like, someone has to do a pre-upgrade flight | 16:59 |
bauzas | we could say 'unsupported until all your computes are upgraded' | 17:00 |
sean-k-mooney | anyway we shoudl dicuss more with the cinder folks | 17:00 |
sean-k-mooney | but we cant just enforce "not supported until all upgraded" in our code just in docs | 17:00 |
bauzas | is there any API impact? tbh I haven't reviewed the spec | 17:00 |
bauzas | hah | 17:00 |
bauzas | sounds to me then a perfect cinder-nova PTG discussion | 17:01 |
bauzas | MengyangZhang[m]: could you join the PTG ? | 17:01 |
bauzas | anyway, we're on time | 17:01 |
bauzas | thanks all | 17:01 |
bauzas | #endmeeting | 17:01 |
opendevmeet | Meeting ended Tue Feb 25 17:01:39 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:01 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-02-25-16.00.html | 17:01 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-02-25-16.00.txt | 17:01 |
opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-02-25-16.00.log.html | 17: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 do | 17:01 |
MengyangZhang[m] | sorry would be my first time joining | 17:02 |
sean-k-mooney | bauzas: no api impact on our side or cinders becuase they dont version this part of the api | 17:02 |
sean-k-mooney | althogh that coudl depend on the ptg dicussion | 17:03 |
bauzas | sean-k-mooney: I definitely need to review the spec then | 17:03 |
sean-k-mooney | one topic MengyangZhang[m] was interested in was a way to refesh the qos on a volume live | 17:03 |
fwiesel | Thanks everyone | 17:03 |
sean-k-mooney | that woul likely need a new instance action | 17:03 |
bauzas | wow | 17:03 |
sean-k-mooney | but i dont think that is in the spec | 17:03 |
bauzas | 'taint my instance' | 17:04 |
sean-k-mooney | bauzas: libvirt supprot updatign them | 17:04 |
sean-k-mooney | we just dont | 17:04 |
bauzas | libvirt can do many things we don't | 17:04 |
MengyangZhang[m] | it's a separate bp and doesn;t have a spec yet | 17:04 |
bauzas | this doesn't mean that we should wrap all libvirt things | 17:04 |
sean-k-mooney | bauzas: its basically asking us to sync nova state with cidner state since it allows it to change without our say so | 17:04 |
bauzas | we're a cloud API, libvirt is an hypervisor | 17:04 |
bauzas | diffreent usecases | 17:05 |
sean-k-mooney | bauzas: today it gets updated on live migration... | 17:05 |
sean-k-mooney | so you update it in cinder and the new atachment used for live migation will get the new qos... | 17:05 |
sean-k-mooney | nova does not offically supprot that | 17:06 |
sean-k-mooney | i personally consier that a but but its apprely what happens today | 17:06 |
bauzas | we had events for cross-project communication, right? | 17:06 |
sean-k-mooney | we do it does nto use that | 17:06 |
sean-k-mooney | its because we only use those event on the volume | 17:06 |
sean-k-mooney | where as they are chging the qos on teh voluem type | 17:06 |
bauzas | anyway, looks we definitely need to design it at the PTG | 17:06 |
sean-k-mooney | basiclly they are updating there version fo a flavor and applying it to all instnaces | 17:07 |
bauzas | and I need to leave now, python meeting downtown | 17:07 |
sean-k-mooney | o/ | 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 site | 17:12 |
opendevreview | Stefan Hoffmann proposed openstack/os-vif master: [ovs] Add method to get external_ids from Interface https://review.opendev.org/c/openstack/os-vif/+/942715 | 17:16 |
vsaienko | hello nova team, please add to your review queue. Fixes non working ironic serial console https://review.opendev.org/c/openstack/nova/+/942575 | 17:35 |
vsaienko | already has +1 from Ironic folks | 17:35 |
JayF | and I think we should be able to backport it given the osdk fix is backporting, too | 17:39 |
opendevreview | Douglas Viroel proposed openstack/nova master: Add support for showing scheduler_hints in server details https://review.opendev.org/c/openstack/nova/+/938604 | 19:07 |
mikal | Morning | 19:09 |
opendevreview | Merged openstack/nova master: Per-Property ImageMetaPropsWeigher https://review.opendev.org/c/openstack/nova/+/941601 | 19:16 |
opendevreview | Douglas Viroel proposed openstack/nova master: DNM - Testing microversion 2.100 changes https://review.opendev.org/c/openstack/nova/+/942728 | 20:07 |
opendevreview | Alan Bishop proposed openstack/nova master: Show swap_progress in attachment details https://review.opendev.org/c/openstack/nova/+/941476 | 21:25 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!