| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-02-18 | |||
| 16:36:43 | sean-k-mooney | gmann: what the state of the tempets testing for this | |
| 16:39:04 | sean-k-mooney | my irc client freeked out so not sure if i missed messages | |
| 16:40:20 | bauzas | sean-k-mooney: gmann was unable to attend the meeting | |
| 16:40:28 | bauzas | so he won't be able to reply to you I guess | |
| 16:40:31 | sean-k-mooney | oh ok. | |
| 16:40:54 | bauzas | fwiw, I don't really know what to do with that spec | |
| 16:41:07 | bauzas | I don't have the context yet and I need some time to reload it | |
| 16:41:14 | bauzas | so I won't be able to +2 it shortly | |
| 16:41:49 | sean-k-mooney | lookign at the tempest patches | |
| 16:42:01 | bauzas | if any other nova-core is able to review that spec, I'm not opposed to a late approval but those two cores shall honestly sign off for the implementation review too | |
| 16:42:38 | sean-k-mooney | so i am not sure ill have time to rewview it either by the way | |
| 16:42:55 | sean-k-mooney | i think this shoudl be moved to next cycle honestly | |
| 16:43:50 | sean-k-mooney | i woudl prefer to focus on merging the ohter approved specs | |
| 16:45:00 | gibi | I dont see cores signing up, so punt it | |
| 16:45:13 | bauzas | that's sad but reasonable | |
| 16:45:22 | bauzas | we shouldn't offer help if we can't review the patches | |
| 16:45:58 | sean-k-mooney | to be clear form my perspecitve this was punted when it missed the sepc freeze | |
| 16:46:12 | sean-k-mooney | and it was not approved as an exption in the team meeting after | |
| 16:46:36 | bauzas | #agreed unfortunately given the review bandwidth and the time it takes to gather context for approving the spec, we can't late approve the spec as we can't also guarantee that we could review the implementation patches in the reasonable timeline that we have | |
| 16:47:52 | bauzas | okay, that was it for today's items in the agenda | |
| 16:47:55 | bauzas | anything anyone ? | |
| 16:47:57 | r-taketn | bauzas: I have one request. (My entry might have been deleted, Sorry for the confusion) | |
| 16:48:35 | MengyangZhang[m] | I also have a topic. https://blueprints.launchpad.net/nova/+spec/enhanced-granularity-and-live-application-of-qos Would like to hear how the community feels about this before moving on looking into the code and writing a spec. Already proposed this idea to cinder and they liked the idea of per-project control of qos and live updating the qos limits. | |
| 16:49:32 | r-taketn | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/244U52T3HINVWUFSMPMA45A67BUPAQGK/ | |
| 16:50:35 | sean-k-mooney | MengyangZhang[m]: we will not provide a inteface to modify cpu qos via cidner forntend qos | |
| 16:50:44 | bauzas | r-taketn: ok, you're the next | |
| 16:50:45 | sean-k-mooney | so if thaty what you plandded -2 | |
| 16:50:59 | sean-k-mooney | but ya lest discuss r-taketn topic first | |
| 16:51:08 | r-taketn | Could you please check the last message the above mailing list and give your comments? | |
| 16:51:25 | sean-k-mooney | r-taketn: sure but just to clarify somethign we said previous | |
| 16:51:35 | sean-k-mooney | nova will not merge any code for unreleased hardware | |
| 16:51:44 | bauzas | r-taketn: oh, OK, that's a follow-up question on Arm-CCA | |
| 16:52:12 | bauzas | yeah, what sean-k-mooney said | |
| 16:52:32 | bauzas | we can't just support something that our operators can't use | |
| 16:53:09 | r-taketn | Oh, ok. I might misunderstand | |
| 16:53:19 | sean-k-mooney | if there are some feautres that will eventually be used by CCA but are useful on there own we can enabel that in advance | |
| 16:54:43 | bauzas | for the sake of the meeting time, could we then move to the second item ? | |
| 16:55:13 | r-taketn | yes | |
| 16:55:54 | bauzas | thanks | |
| 16:56:03 | bauzas | MengyangZhang[m]: looking at your blueprint | |
| 16:56:07 | sean-k-mooney | MengyangZhang[m]: to be clear "live QoS updates to CPU and memory limits, including configurations in cputune, cachetune, and memorytune libvirt XML elements to enable seamless performance adjustments for running instances." is not something we can or shoudl supprot via cidner frontend qos policies | |
| 16:56:34 | sean-k-mooney | if we wanted to do that we woudl need to add a new QOS api to nova to allows admins to defien qos polices | |
| 16:56:43 | sean-k-mooney | and a instance action to apply it | |
| 16:56:45 | bauzas | that sounds a very large topic to discuss | |
| 16:57:03 | bauzas | haven't we already proposed to discuss those kind of topics at the PTG ? | |
| 16:57:16 | sean-k-mooney | i tought so | |
| 16:57:22 | MengyangZhang[m] | <sean-k-mooney> "Mengyang Zhang: we will not..." <- It's not via cinder qos. What we want to achieve is to be able to live update all QoS limits on existing VMs on nova side. For disk qos, it's a bit special as it requires cinder side changes. | |
| 16:57:40 | bauzas | I actually see it in https://etherpad.opendev.org/p/nova-2025.2-ptg#L47 | |
| 16:57:51 | bauzas | so I'd recommend to defer the discussion at the PTG | |
| 16:57:55 | sean-k-mooney | MengyangZhang[m]: so the only qos you can configure today in nova | |
| 16:58:00 | sean-k-mooney | is via flavor extra specs | |
| 16:58:14 | sean-k-mooney | so what you are effectivly asking for is a limited form of live resize | |
| 16:59:33 | MengyangZhang[m] | we can set cpu and memory qos via flavor extra specs. But cinder is a bit different. | |
| 17:00:14 | sean-k-mooney | you can set disk qos via flavor extra specs too. | |
| 17:00:49 | bauzas | we're over time | |
| 17:00:50 | sean-k-mooney | cidner qos today coudl be supproted via swap voluem (volume retype in cinder) | |
| 17:00:57 | bauzas | thanks folks | |
| 17:01:10 | bauzas | I'll end the meeting but I also recommend talking about that usecase at the PTG | |
| 17:01:12 | bauzas | thnaks | |
| 17:01:15 | bauzas | #endmeeting | |
| 17:01:15 | opendevmeet | Meeting ended Tue Feb 18 17:01:15 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:01:15 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-02-18-16.01.html | |
| 17:01:15 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-02-18-16.01.txt | |
| 17:01:15 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-02-18-16.01.log.html | |
| 17:01:42 | sean-k-mooney | MengyangZhang[m]: i think we woudl need a nova cinder corss project seesion on this topic for the cinder case | |
| 17:02:32 | cardoe | https://review.opendev.org/c/openstack/nova/+/942019 is just a simple message fix that I was gonna see if I could also backport to 2024.2 (and technically affects back to 2024.1) Not sure if there's some test or release note you guys would like me to add. | |
| 17:02:51 | MengyangZhang[m] | Yes, make sense. So we discuss it on Thur? | |
| 17:02:54 | r-taketn | thanks | |
| 17:09:03 | MengyangZhang[m] | ||
| 17:09:23 | sean-k-mooney | MengyangZhang[m]: likely how we would need to do this si to add a new external event that cidner could call back when qos is modifed on a volume | |
| 17:10:28 | sean-k-mooney | we would also need to call them back to etier complet the update or fail it | |
| 17:12:21 | MengyangZhang[m] | make sense. I can look into this a bit more closely, but since this may be a large project, just want to make sure the community is interested in the idea so we can start working on it in my company | |
| 17:12:25 | sean-k-mooney | MengyangZhang[m]: have you written a cidner spec for this yet? i suspect we will need one for cinder and another for nova as it would need api change on both sides | |
| 17:13:27 | MengyangZhang[m] | not yet, yes spec makes complete sense. will work on it next | |
| 17:13:47 | sean-k-mooney | MengyangZhang[m]: this is similar compelxtity to https://specs.openstack.org/openstack/nova-specs/specs/2024.2/approved/assisted-volume-extend.html | |
| 17:14:10 | sean-k-mooney | https://review.opendev.org/c/openstack/cinder-specs/+/866718 | |
| 17:15:17 | sean-k-mooney | MengyangZhang[m]: while POC are useful in general its expected to agree the design in a spec before working on the code | |
| 17:16:58 | sean-k-mooney | if we focus on the cidner usecase what your really tryign to adress is the gap for frontend qos when you do "openstack volume qos associate QOS_ID VOLUME_TYPE_ID" | |
| 17:19:00 | sean-k-mooney | ... why are they using a get request to make a change... | |
| 17:19:03 | sean-k-mooney | https://docs.openstack.org/api-ref/block-storage/v3/index.html?expanded=detach-volume-from-server-detail#associate-qos-specification-with-a-volume-type | |
| 17:19:09 | MengyangZhang[m] | For cinder, there are two requests, one is per project qos not the per volume type qos. Secondly, once the qos policy is changed, we want to let the existing vm automatically adopt the new limits instead of requireing a live-migration to adopt it | |
| 17:19:09 | sean-k-mooney | anyway that return a 202 | |
| 17:19:54 | sean-k-mooney | today it shoudl eb returing a 409 conflict if the volume is attached to and isntance and the qos policy has frontent qos | |
| 17:20:30 | sean-k-mooney | MengyangZhang[m]: live migration shoudl not cause it to update today | |
| 17:20:52 | sean-k-mooney | if it does that proably a bug | |
| 17:21:34 | sean-k-mooney | i stongly suspect that cidner api is not propelry reject assocateing a qos policy with a volume that is in-use when the policy has front end qos | |
| 17:21:43 | sean-k-mooney | it it allows that today that is wrong | |
| 17:25:24 | MengyangZhang[m] | Let me double check it | |
| 17:26:16 | sean-k-mooney | it woudl be a prety seriours api bug on there side | |
| 17:26:39 | sean-k-mooney | because they would allow the requested state and the actual state to get out of sync | |
| 17:27:00 | sean-k-mooney | which could lead to late failure the next tiem a user hard reboots an instnace | |
| 17:30:03 | MengyangZhang[m] | I will perform some testing locally and get back to you on this | |
| 17:30:49 | sean-k-mooney | if you can apply a qos policy to a volume that is in use and that policy has a frontend qos rule then its a cidner api bug form my perspecitve | |
| 17:31:21 | sean-k-mooney | its not ok to make a change i nthe cinder api and only have it take effect potentialy month later the next time the vm is moved or the xml is otherwise regenerated | |
| 17:32:46 | sean-k-mooney | the current api is written in terms of the volume type | |
| 17:32:56 | sean-k-mooney | nto in terms fo a volume | |
| 17:33:58 | sean-k-mooney | cinder shoudl not apply the qos update to existing instance or the updated type until a retyp or simialr api call is done | |
| 17:41:36 | opendevreview | Sylvain Bauza proposed openstack/nova master: Add a new ImagePropertiesWeigher https://review.opendev.org/c/openstack/nova/+/940642 | |
| 17:41:37 | opendevreview | Sylvain Bauza proposed openstack/nova master: per-property ImageMetaPropsWeigher https://review.opendev.org/c/openstack/nova/+/941601 | |
| 17:48:24 | MengyangZhang[m] | <sean-k-mooney> "its not ok to make a change i..." <- unfortunately, that's the case now. If a qos policy is created and associated with a volume type, then all in-use volumes of that type will get qos limits when the xml is regenerated, like during live migration or resize. | |