| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-02-25 | |||
| 16:46:02 | 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:05 | dansmith | sean-k-mooney: especially since it appearently already exist: https://libvirt.org/drvch.html | |
| 16:46:19 | sean-k-mooney | and beyond that how you plan to test and develop supproted for it on an ongoing basis | |
| 16:46:58 | sean-k-mooney | tpressure: well we dont generate qemu calls today | |
| 16:47:10 | sean-k-mooney | nova generate a semi hypervior indepent xml | |
| 16:47:31 | sean-k-mooney | we "supprot" libvirt with lxc, qemu and i think openvz | |
| 16:47:47 | sean-k-mooney | althoug everything excpt for qemu is basiclly not tested or maintaiend anymore | |
| 16:48:19 | 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:31 | hertrste | yeah we know of that support | |
| 16:48:36 | sean-k-mooney | so the question woudl be what does a full virt driver provide that cant be done vai that | |
| 16:49:04 | dansmith | and more than that, why would it be worth maintaining that *and* a separate full nova driver | |
| 16:49:29 | dansmith | like, what will never be possible via libvirt that would be if we have a whole separate implementation in nova | |
| 16:49:31 | 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:53 | 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:50:03 | 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:31 | sean-k-mooney | the main concern i would have iwth the current poc | |
| 16:50:41 | sean-k-mooney | is its directly invoking a command line client correct | |
| 16:50:52 | 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:51:01 | sean-k-mooney | which means you are commiting to providign a forward compatiable stable cli fro nova to use | |
| 16:51:40 | bauzas | folks, because we have another item to discuss, can we stop here ? | |
| 16:51:46 | 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:59 | sean-k-mooney | sure we can move on | |
| 16:52:05 | dansmith | bauzas: yes, I have to run anyway.. but a preview of my concerns for PTG :) | |
| 16:52:06 | sean-k-mooney | dansmith: ack | |
| 16:52:19 | hertrste | thanks for the feedback | |
| 16:52:30 | bauzas | hertrste: ping me if you have any questions about the PTG, I'll try to answer your concerns | |
| 16:52:40 | bauzas | moving on then | |
| 16:52:50 | bauzas | (mzhang741) Add Burst Length Support to Cinder QoS | |
| 16:52:58 | bauzas | is mzhang741 here ? | |
| 16:53:05 | MengyangZhang[m] | yes | |
| 16:53:08 | bauzas | https://review.opendev.org/c/openstack/nova-specs/+/932653 | |
| 16:53:42 | bauzas | seems to me a design question | |
| 16:53:53 | bauzas | could we just do this in the gerrit change review ? | |
| 16:54:11 | bauzas | do we need a quorum consensus ? | |
| 16:55:58 | MengyangZhang[m] | besides that min version check question, also need review and approval of the spec to move forward | |
| 16:56:29 | bauzas | MengyangZhang[m]: that's our usual review cycle | |
| 16:56:44 | bauzas | but for the moment, even 2025.2 work hasn't started | |
| 16:56:59 | bauzas | so please understand that people have other priorities for now | |
| 16:57:34 | bauzas | MengyangZhang[m]: the best if you want is to have a cross-project discussion with the cinder folks at the PTG | |
| 16:57:46 | sean-k-mooney | bauzas: context for this | |
| 16:57:50 | bauzas | that would I guess answer most of the design questions, and it would be quick | |
| 16:58:01 | 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:06 | 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:24 | sean-k-mooney | it turns out that cinder allows you to update the qos on a volume type | |
| 16:58:28 | bauzas | sean-k-mooney: that's the usual upgrade pattern yeah | |
| 16:58:37 | sean-k-mooney | and it will take effect to all volumes of that type | |
| 16:58:42 | sean-k-mooney | on the next move op | |
| 16:58:50 | sean-k-mooney | or when we next update the attachment | |
| 16:59:06 | bauzas | so even old computes would see it ? | |
| 16:59:07 | sean-k-mooney | so cinder is not caching it liek we do with the falvor/image properties when the volume is created | |
| 16:59:10 | sean-k-mooney | yep | |
| 16:59:21 | sean-k-mooney | so this is a pre exisitng upgrade problem | |
| 16:59:24 | bauzas | that's an harder upgrade pattern to solve | |
| 16:59:30 | bauzas | yeah, sounds | |
| 16:59:43 | bauzas | like, someone has to do a pre-upgrade flight | |
| 16:59:43 | sean-k-mooney | so i dont think we can actully really protect agaisnt this in nova | |
| 17:00:04 | bauzas | we could say 'unsupported until all your computes are upgraded' | |
| 17:00:06 | sean-k-mooney | anyway we shoudl dicuss more with the cinder folks | |
| 17:00:32 | sean-k-mooney | but we cant just enforce "not supported until all upgraded" in our code just in docs | |
| 17:00:33 | bauzas | is there any API impact? tbh I haven't reviewed the spec | |
| 17:00:39 | bauzas | hah | |
| 17:01:00 | bauzas | sounds to me then a perfect cinder-nova PTG discussion | |
| 17:01:13 | bauzas | MengyangZhang[m]: could you join the PTG ? | |
| 17:01:29 | bauzas | anyway, we're on time | |
| 17:01:35 | bauzas | thanks all | |
| 17:01:39 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-02-25-16.00.log.html | |
| 17:01:39 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-02-25-16.00.txt | |
| 17:01:39 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-02-25-16.00.html | |
| 17:01:39 | 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:39 | bauzas | #endmeeting | |
| 17:01:45 | 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:02:04 | MengyangZhang[m] | sorry would be my first time joining | |
| 17:02:40 | sean-k-mooney | bauzas: no api impact on our side or cinders becuase they dont version this part of the api | |
| 17:03:17 | sean-k-mooney | althogh that coudl depend on the ptg dicussion | |
| 17:03:25 | bauzas | sean-k-mooney: I definitely need to review the spec then | |
| 17:03:34 | sean-k-mooney | one topic MengyangZhang[m] was interested in was a way to refesh the qos on a volume live | |
| 17:03:37 | fwiesel | Thanks everyone | |
| 17:03:40 | sean-k-mooney | that woul likely need a new instance action | |
| 17:03:48 | bauzas | wow | |
| 17:03:54 | sean-k-mooney | but i dont think that is in the spec | |
| 17:04:04 | bauzas | 'taint my instance' | |
| 17:04:06 | sean-k-mooney | bauzas: libvirt supprot updatign them | |
| 17:04:12 | sean-k-mooney | we just dont | |
| 17:04:15 | bauzas | libvirt can do many things we don't | |
| 17:04:19 | MengyangZhang[m] | it's a separate bp and doesn;t have a spec yet | |
| 17:04:37 | bauzas | this doesn't mean that we should wrap all libvirt things | |
| 17:04:52 | 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:54 | bauzas | we're a cloud API, libvirt is an hypervisor | |
| 17:05:05 | bauzas | diffreent usecases | |
| 17:05:22 | sean-k-mooney | bauzas: today it gets updated on live migration... | |
| 17:05:41 | sean-k-mooney | so you update it in cinder and the new atachment used for live migation will get the new qos... | |
| 17:06:14 | sean-k-mooney | nova does not offically supprot that | |
| 17:06:26 | sean-k-mooney | i personally consier that a but but its apprely what happens today | |
| 17:06:27 | bauzas | we had events for cross-project communication, right? | |
| 17:06:36 | sean-k-mooney | we do it does nto use that | |
| 17:06:45 | sean-k-mooney | its because we only use those event on the volume | |
| 17:06:53 | sean-k-mooney | where as they are chging the qos on teh voluem type | |
| 17:06:58 | bauzas | anyway, looks we definitely need to design it at the PTG | |
| 17:07:09 | sean-k-mooney | basiclly they are updating there version fo a flavor and applying it to all instnaces | |
| 17:07:16 | bauzas | and I need to leave now, python meeting downtown | |