| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-10-31 | |||
| 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 | |
| 16:33:25 | gmann | this is something we discussed on Monday PTG but left nova specific discussion for later | |
| 16:33:47 | gmann | sean-k-mooney: has idea of passing user as well service token in service-only-APIs whihc is also listed in etherpad | |
| 16:34:50 | sean-k-mooney | right so when swap volume is called by cinder on behalf of user sean | |
| 16:34:58 | gmann | sean-k-mooney: if I understand your idea correct you want to do it same way we do currently right? passing service token as header in user token - https://github.com/openstack/nova/blob/b37d50fecc92c17c3b30e41f6ad8869e1f9bd2ef/nova/service_auth.py#L33 | |
| 16:35:02 | sean-k-mooney | we shoudl be recordign that as coming form sean not cinder | |
| 16:35:45 | sean-k-mooney | gmann: yes it would be the presence fo a service token(with service role) in the header and any other token that would make it a service request | |
| 16:36:20 | bauzas | I'm a bit confused here | |
| 16:36:29 | bauzas | probably because I'm not an expert | |
| 16:36:33 | gmann | and that service token can be used to know if request is from service or not. if not then 403. | |
| 16:36:34 | sean-k-mooney | the user token is so we knwo on behlaf of which (user/project) the request was made | |
| 16:36:38 | dansmith | authorized by the service token but limited in scope (and recorded in audit) as the user | |
| 16:36:43 | bauzas | but I thought we were already providing both tokens ? | |
| 16:36:49 | sean-k-mooney | dansmith: exactly | |
| 16:37:13 | gmann | bauzas: we do but we do not check service token is must provided or not | |
| 16:37:23 | sean-k-mooney | bauzas: we are but some of these api are admin only today | |
| 16:37:26 | bauzas | okay, so that's a question server-side ? | |
| 16:37:27 | gmann | dansmith: sean-k-mooney so if no service token presence in those servcei-ony API then 403 right? | |
| 16:37:37 | sean-k-mooney | so the user token in that case is an admin token created form the config for the cinder user | |
| 16:37:46 | sean-k-mooney | gmann: yes | |
| 16:37:55 | gmann | cool. | |
| 16:37:58 | sean-k-mooney | 403 if service token is not passed | |
| 16:38:13 | sean-k-mooney | when callling swap volume or external events api for example | |
| 16:38:33 | gmann | yeah, we do not check that currently so it will achieve the same thing we wanted via policy default | |
| 16:38:36 | sean-k-mooney | for compatiblity we are currently supproting "service or admin" right | |
| 16:39:00 | gmann | it is admin only no service but that is going to be "service or admin" | |
| 16:39:01 | sean-k-mooney | meaning we woudl allow it if the user token was an admin token or if there was an addtional service token | |
| 16:39:16 | gmann | I mean "<whatever default currently admin or member + service role>" | |
| 16:40:14 | sean-k-mooney | so on the devstack side oen thing we shoudl do eventually is have a way to make sure the service_user does nto have admin in its role assignemtns | |
| 16:40:43 | gmann | I am thinking 1. fetch the service token form header 2. use that as target in oslo policy so that if no service role then it fail | |
| 16:41:10 | sean-k-mooney | for the service_only policy rihgt | |
| 16:41:15 | gmann | yes | |
| 16:41:21 | sean-k-mooney | for the service_or_admin we would need to fall back | |
| 16:41:26 | gmann | and policy default will be "admin or service" | |