| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-02-18 | |||
| 16:22:16 | sean-k-mooney | then remove next cycle | |
| 16:22:23 | gibi | I'm OK to deprecate and disable. We cannot really do anything else if neutron pulled the plug | |
| 16:22:44 | sean-k-mooney | ill submit the patch for that for nova later today | |
| 16:22:48 | sean-k-mooney | i jsut need to write it | |
| 16:23:05 | bauzas | yeah I think we can agree | |
| 16:23:19 | sean-k-mooney | we are not fully blocked as the linux bridge job only tirggers on a subset of files | |
| 16:23:24 | bauzas | send the deprecation signal and remove the job | |
| 16:24:18 | bauzas | anyone having concerns by the deprecation ? | |
| 16:25:02 | sean-k-mooney | nova in 2025.1 woudl be able to run with older neutron or with linux bridge if you wrote an out of tree ml2/driver | |
| 16:25:13 | sean-k-mooney | so i will note that in the release note | |
| 16:25:47 | sean-k-mooney | but i dont expect that we will need/want to supprot that going forward. we can have that discssion before doing the removal form nova itslef | |
| 16:26:12 | sean-k-mooney | the thing is os-vif does nto host plugins for out of tree neutron backends | |
| 16:26:25 | sean-k-mooney | so we shoudl remove the os-vif supprot in os-vif next cycle in either case | |
| 16:26:42 | sean-k-mooney | anyway thats all form me | |
| 16:27:38 | bauzas | cool thanks | |
| 16:28:14 | bauzas | #agreed linuxbridge will be deprecated by 2025.1 | |
| 16:28:30 | bauzas | next time | |
| 16:28:38 | bauzas | gmann (I will not be able to attend the meeting due to a time conflict, but most of you know the context and proposal), Spec freeze exception for RBAC service/manager role | |
| 16:28:49 | bauzas | #link https://review.opendev.org/c/openstack/nova-specs/+/937650 | |
| 16:29:43 | bauzas | gmann requested for a late specless approval | |
| 16:29:53 | bauzas | spec approval (my bad) | |
| 16:30:01 | bauzas | Spec has one +2 already and code changes are in progress: https://review.opendev.org/q/topic:%22bp/policy-service-and-manager-role-default%22 | |
| 16:30:47 | bauzas | usually we would not approve a spec so late in the cycle, but there are some criterias here to talk | |
| 16:31:01 | bauzas | 1/ the spec is quite simple and only relates to policy changes | |
| 16:31:37 | bauzas | 2/ we already merged some efforts related to policy | |
| 16:31:50 | bauzas | 3/ sean-k-mooney already accepted the spec | |
| 16:32:00 | bauzas | would there any concern by the approval ? | |
| 16:32:34 | sean-k-mooney | yes, although that was with the coment it needs an execption and the undersanding we woudl have this converstaion about 4 weeks ago | |
| 16:32:52 | sean-k-mooney | from me just review bandwith | |
| 16:32:58 | bauzas | my personal opinion on that is the risk about the policy changes | |
| 16:33:19 | gibi | yeah, if there are two cores signing up for reviewing it the I have no objection | |
| 16:33:26 | gibi | but the time is pretty sort | |
| 16:33:28 | bauzas | we're talking of modifying the inter-service communication | |
| 16:33:37 | sean-k-mooney | we are but | |
| 16:33:46 | bauzas | so the patches would require extra caution | |
| 16:33:59 | sean-k-mooney | by defualt i this cycle swe will go form admin to admin or service | |
| 16:34:07 | bauzas | I'm not opposed to give that series a late approval, but I wouldn't rush on reviewing the patches to be clear | |
| 16:34:17 | sean-k-mooney | so the real upgrade impact woudl be next cycle or whenever we drop admin | |
| 16:34:27 | sean-k-mooney | the manager changes would also be additive | |
| 16:35:32 | sean-k-mooney | we obviouly need to validate that our exsing jobs do not require modfiigcaiont to pass | |
| 16:35:40 | sean-k-mooney | to ensure there is no upgrade impact | |
| 16:36:06 | sean-k-mooney | we may also want to explcity have the new defautl job enable extra testing fo the manager policy | |
| 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 | |