Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-02-18
16:15:14 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:15:35 elodilles note that it will directly go to End of Life as it is not a SLURP release
16:15:48 elodilles #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:15:56 elodilles and that's all from me
16:18:20 fwiesel I suspect it is my turn.
16:18:21 fwiesel #topic vmwareapi 3rd-party CI efforts Highlights
16:18:29 fwiesel No updates from my side.
16:18:29 bauzas thanks fwiesel
16:18:34 bauzas cool thanks
16:18:45 bauzas still fighting the dragons ?
16:19:25 fwiesel Yes, I didn't quite get around to it, that is the main reason of the lack of progress.
16:19:36 bauzas no worries, we all have urgent business to sell
16:19:42 bauzas moving on then
16:19:53 bauzas #topic Open discussion
16:20:00 bauzas two items today AFAICS
16:20:07 bauzas (sean-k-mooney) neutron removal of linux bridge
16:20:09 bauzas sean-k-mooney: around N?
16:20:14 sean-k-mooney yep
16:20:28 sean-k-mooney so... neutron removed linxu bridge
16:20:38 sean-k-mooney they did not deprecated it in the last slurp
16:20:42 sean-k-mooney so we never did
16:20:55 sean-k-mooney so my propsoal is we deprecate it this release
16:21:03 sean-k-mooney disable the linux bridge job
16:21:09 sean-k-mooney and remove supprot next cycle
16:21:14 sean-k-mooney we need to do this in os-vif as well
16:21:18 sean-k-mooney i have a patch up for that
16:21:33 sean-k-mooney os-vif is subject to the non clinet lib freeze and is currently blocked
16:21:37 sean-k-mooney form merging code because of this
16:21:47 sean-k-mooney we have some patches we want to merge before then
16:21:55 sean-k-mooney so the topci is, are we ok with that plan
16:22:01 sean-k-mooney deprecate and disbales testing this cycle
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

Earlier   Later