Earlier  
Posted Nick Remark
#openstack-nova - 2023-10-31
16:10:59 bauzas https://etherpad.opendev.org/p/nova-caracal-ptg#L175 said R-22 would be our spec review day
16:12:01 sean-k-mooney bauzas: i gues syou did say r-22
16:12:07 sean-k-mooney i feel like that was a mistak
16:12:37 sean-k-mooney i tought i suggested m1 for that bvut no worries
16:12:38 bauzas no, I remember we said 'the week after PTG'
16:12:41 sean-k-mooney we can do it next week
16:13:02 bauzas m-1 was for reviewing implementations
16:13:03 sean-k-mooney oh we are doing the implemation review day on m1
16:13:12 sean-k-mooney yep
16:13:25 sean-k-mooney so ya we missed the first sepc review day
16:13:34 bauzas yeah, my fault
16:13:37 sean-k-mooney honestly im still burnt out form ptg so next week woudl be better
16:13:39 bauzas -ETOOMANYTHINGS
16:13:49 bauzas okay, agreed
16:14:15 bauzas #info Next Tuesday (Nov 7) we will have a spec review day
16:14:24 bauzas #action bauzas to community on that review day
16:14:27 bauzas #unfo
16:14:31 bauzas #undo
16:14:31 opendevmeet Removing item from minutes: #action bauzas to community on that review day
16:14:39 bauzas #action bauzas to communicate on that review day
16:15:13 bauzas I'll also communicate the implementation review day in 2 weeks from now
16:15:35 bauzas moving on
16:15:38 bauzas #topic Caracal vPTG planning
16:15:42 bauzas #undo
16:15:42 opendevmeet Removing item from minutes: #topic Caracal vPTG planning
16:15:52 bauzas #topic Caracal vPTG wrapup
16:15:59 bauzas #link https://etherpad.opendev.org/p/nova-caracal-ptg PTG etherpad
16:16:18 bauzas I have some draft in my emailbox that I need to eventually write
16:16:31 bauzas I just don't know when yet
16:16:42 bauzas for the moment, please look at the etherpad
16:16:53 elodilles ++
16:17:00 bauzas we had one single topic we were unable to talk
16:17:01 sean-k-mooney bauzas: wehn you send the eamil
16:17:11 sean-k-mooney please use the readonly link for the etherpad
16:17:27 bauzas like every cycle I do ? sure
16:17:46 bauzas I already did
16:17:46 sean-k-mooney ack not everyone does
16:17:53 bauzas + I downloaded a text file
16:18:01 gmann ++
16:18:15 bauzas and I tagged the latest rev
16:18:39 bauzas sean-k-mooney: look at summary emails I write for a long time now
16:18:58 bauzas you'll see what I provide
16:19:02 bauzas anyway
16:19:06 bauzas #topic Review priorities
16:19:27 bauzas we agreed on something last week, so I'll punt this topic for this week
16:19:40 bauzas #topic Stable Branches
16:19:43 bauzas elodilles: please
16:19:48 elodilles o7
16:19:55 elodilles stable/2023.2 branch was broken due to openstacksdk-functional-devstack job, but it is fixed -- https://review.opendev.org/c/openstack/openstacksdk/+/899154
16:20:08 elodilles thanks gmann for pinging me about this ^^^
16:20:18 elodilles other stable gates state should be also OK
16:20:44 elodilles (or at least i'm not aware of any issue)
16:20:45 bauzas cool
16:20:49 elodilles stable release patches proposed: https://review.opendev.org/q/project:openstack/releases+is:open+intopic:nova
16:21:06 elodilles so release liaisons please review ^^^
16:21:10 bauzas yeah I need to review them
16:21:12 elodilles we might not need all of them
16:21:20 bauzas that said, I have some bugfix I'd like to backport :)
16:21:26 bauzas but let's not wait for it :)
16:21:30 bauzas or
16:21:33 bauzas as you want
16:21:34 gmann also, these hyperV and vmware driver deprecation backport to stable/2023.1 are ready for 2nd review https://review.opendev.org/q/topic:deprecate-virt-drivers+status:open
16:21:37 elodilles if you want to wait for any bugfix, then just -1 it
16:21:43 gmann thanks bauzas for reviews.
16:21:47 bauzas actually I have two series I want to backport
16:21:53 gmann maybe it will be good to include those in releases elodilles mentioned
16:22:03 bauzas the compute rpc fix and the sriov gpu fix
16:22:16 bauzas elodilles: could we then wait a little bit before releasing ?
16:22:26 elodilles bauzas: for sure
16:22:52 bauzas elodilles: if you don't mind, I'll -1 the release patches
16:22:53 dansmith the compute rpc one for sure!
16:23:09 bauzas I need to create the backports
16:23:11 dansmith sorry someone was at the door when we talked about gate stability,
16:23:21 dansmith but I've had to recheck those a few times now, all for different reasons :(
16:23:22 bauzas np
16:23:28 dansmith feels like we're slipping here
16:23:39 bauzas I've seen multi-cell
16:23:56 bauzas but I haven't yet looked at *what* failed for this job
16:24:08 dansmith each one I've looked at has been a different thing
16:24:17 bauzas lovely
16:25:08 bauzas something due to some stuff with 'v' name that ends by 'olume' ?
16:25:22 dansmith some, but not all
16:25:46 bauzas if that's something starting with 'n' and ending by 'etwork' I can understand
16:26:08 bauzas anyway, I need to do homework, I just don't know yet when
16:27:59 bauzas okay, I guess we're done with stable
16:28:13 elodilles ah, maybe the general info:
16:28:15 bauzas nothing we need to discuss for now, we just need to look
16:28:20 elodilles #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:28:28 bauzas ah yeah
16:28:35 elodilles and that's all :)
16:28:36 bauzas #topic Open discussion
16:28:45 bauzas gmann: wants to talk the topic you had ?
16:29:04 bauzas (gmann) RBAC: service role usage for Nova to talk to other services
16:29:05 gmann oh, which one?
16:29:12 gmann k
16:29:21 bauzas #link https://etherpad.opendev.org/p/nova-caracal-ptg#L871
16:30:08 gmann there are some notes there on the thing I wanted to discuss. we discussed it long back on how to proceed on service role
16:30:59 gmann which was 1. make policy default to service role only 2. accept service token in API 3. use nova generated admin context whereever it is required (for example getting servers in server external event API)
16:32:21 gmann but when I was doing it for swap volume API (which is lot o call from cinder to nova and nova to cinder), it end up that we need to use admin context for almost all the operations in this API. so it looks like we are going to make policy default to service role only and use service token to just check it is called from service not form user
16:32:40 gmann BUT use admin context for all actual operations

Earlier   Later