| opendevreview | Ghanshyam proposed openstack/governance master: Select secure and consistent RBAC as a community-wide goal https://review.opendev.org/c/openstack/governance/+/818817 | 01:57 |
|---|---|---|
| opendevreview | Ghanshyam proposed openstack/governance master: Move completed goals into the completed directory https://review.opendev.org/c/openstack/governance/+/818845 | 02:27 |
| *** pojadhav is now known as pojadhav|afk | 05:58 | |
| *** pojadhav|afk is now known as pojadhav | 06:36 | |
| *** ykarel is now known as ykarel|lunch | 09:21 | |
| *** pojadhav is now known as pojadhav|afk | 11:32 | |
| *** ykarel|lunch is now known as ykarel | 12:05 | |
| *** pojadhav|afk is now known as pojadhav | 12:17 | |
| *** ykarel is now known as ykarel|afk | 12:41 | |
| *** ykarel|afk is now known as ykarel | 14:02 | |
| dansmith | gmann: you're going to have the tc meeting without all the us people? | 15:13 |
| *** ykarel is now known as ykarel|away | 15:55 | |
| lbragstad | rosmaita o/ | 16:21 |
| rosmaita | 0/ | 16:21 |
| lbragstad | hey TC folks | 16:21 |
| lbragstad | rosmaita brought up a point about domain personas in https://review.opendev.org/c/openstack/governance/+/815158 | 16:21 |
| lbragstad | i think it's valid that we need to include something in that document about when services need to implement that | 16:22 |
| lbragstad | if we do it in Yoga - it feels like scope creep | 16:22 |
| lbragstad | if we do it in Zena - we're "breaking" a current work flow for operators | 16:22 |
| lbragstad | (for at least a release) | 16:22 |
| lbragstad | s/Zena/Z-release/ | 16:24 |
| rosmaita | you have my vote for the name of Z, especially my suggestion of "You" got rejected for Y | 16:24 |
| * lbragstad shakes head | 16:25 | |
| lbragstad | i do that all the time with xena and z because of how it sounds | 16:25 |
| rosmaita | me too | 16:25 |
| rosmaita | actually, looking at your timeline | 16:27 |
| rosmaita | enforce_scope=True would happen before Z release | 16:27 |
| rosmaita | so i think we could move the domain implementation to early Z | 16:28 |
| rosmaita | and still turn on scope, and not break operators? | 16:28 |
| lbragstad | well - that's not going to allow an operator to ask nova for all instances across the entire deployment | 16:28 |
| lbragstad | i think that will still be broken | 16:28 |
| lbragstad | because system-admin can't list all instances in the deployment | 16:29 |
| lbragstad | and project-admin is only going to be able to list instances within the project they have authorization on | 16:29 |
| lbragstad | right? | 16:29 |
| johnthetubaguy[m] | so the current patch, I think system-admin is allowed to list all instances, as a comprimise | 16:29 |
| johnthetubaguy[m] | https://review.opendev.org/c/openstack/nova/+/816206/7/nova/policies/servers.py#60 | 16:30 |
| rosmaita | scope type is project on that rule, though | 16:31 |
| johnthetubaguy[m] | oh sorry, I got confused, yes | 16:31 |
| rosmaita | ok | 16:31 |
| lbragstad | yeah - so if we don't add domain support for yoga - that will be broken | 16:31 |
| rosmaita | but only if enforce_scope=True, right? | 16:32 |
| lbragstad | yes | 16:32 |
| rosmaita | and exept for keystone, i think no one will have enforce_scope=True in yoga release? | 16:33 |
| lbragstad | well - one or two services might | 16:33 |
| lbragstad | i think the idea is that everyone should develop yoga so that it can be run with enforce_scope: True | 16:33 |
| rosmaita | well, i think we say, "don't turn it on if you don't support domain scope yet" | 16:33 |
| rosmaita | oh, well if that's the idea, then we need domain support in Yoga | 16:34 |
| lbragstad | yeah - that could be something we document | 16:34 |
| lbragstad | "hey, you get all these personas, but this use case is broken until Z" | 16:34 |
| lbragstad | and we add the domain support case to Z as a target | 16:34 |
| lbragstad | in addition to the system-member and system-reader | 16:35 |
| lbragstad | this affects johnthetubaguy[m] way more than me, so i'm curious to see what he says | 16:35 |
| rosmaita | i think that's ok, i don't know how many people will make the move until multiple services support s-rbac | 16:35 |
| rosmaita | though johnthetubaguy[m] may have a different idea | 16:35 |
| johnthetubaguy[m] | so step one, with no scope checks, its an admin thing, regardless of project/domain/system discussions | 16:36 |
| johnthetubaguy[m] | at least we agreed on that bit | 16:36 |
| johnthetubaguy[m] | I guess the problem then is, what is the easiest route to turn on scope checking, and how does it help you move forward | 16:36 |
| johnthetubaguy[m] | the domain admin bit I care about most is probably the client being able to get the correct token for instance reboot / live-migration etc | 16:37 |
| johnthetubaguy[m] | as in the CLI working correctly is a big blocker here | 16:38 |
| johnthetubaguy[m] | or rather, we need the CLI to work nicely before its reasonable for users to start dropping the deprecated policy rules | 16:38 |
| lbragstad | ok - so it sounds like having the CLI do the right thing is more important than the domain user support | 16:41 |
| lbragstad | ? | 16:41 |
| johnthetubaguy[m] | (this is my thinking face, via a text medium) | 16:41 |
| johnthetubaguy[m] | lbragstad: +1 I think it is, otherwise operators are in a right mess | 16:41 |
| lbragstad | ok - so 1. client fetches all projects for a domain 2. iterates through each project to list instances 3. aggregates the list and presents it to the user | 16:42 |
| lbragstad | that would allow `openstack --os-cloud domain-admin instance list --all-projects` | 16:42 |
| lbragstad | but purely based on clientcode | 16:43 |
| lbragstad | no service level API changes for support domain users | 16:43 |
| lbragstad | supporting* | 16:43 |
| rosmaita | (i am in another meeting, so delayed in reading here) | 16:44 |
| johnthetubaguy[m] | I am not sure if the above works without changes mind :/ | 16:44 |
| johnthetubaguy[m] | so today they basically have system admin and domain admin and project admin on all projects with a single config | 16:45 |
| johnthetubaguy[m] | so for the first step, turn off deprecated rules, you would need to get a project token for the correct project, for many of those APIs | 16:46 |
| johnthetubaguy[m] | for some APIs it should be a system scoped admin, but until we enforce scopes, any admin will do | 16:46 |
| johnthetubaguy[m] | as such domain admin would pass the system admin role checks, and let you get tokens in the correct projects | 16:47 |
| johnthetubaguy[m] | so I guess that would work ... (thinking face) | 16:47 |
| johnthetubaguy[m] | the next step is the need for the system vs domain destinction | 16:47 |
| lbragstad | ok - in that case | 16:47 |
| johnthetubaguy[m] | so to list all hosts, to pick one for live-migration, you would use system, then you do domain/project admin for the live-migration | 16:48 |
| lbragstad | you're not using enforce_scope = True | 16:48 |
| johnthetubaguy[m] | yes, this is pre enforce_scope = true | 16:48 |
| lbragstad | oh | 16:48 |
| lbragstad | and enforce_new_defaults = True? | 16:48 |
| johnthetubaguy[m] | yeah | 16:48 |
| johnthetubaguy[m] | i.e. step 1 in the list | 16:48 |
| lbragstad | ok | 16:49 |
| johnthetubaguy[m] | the only real change is that the project admin token now needs to match the project_id, for the regular operator | 16:49 |
| johnthetubaguy[m] | the bonus is, we get project reader and project member distinctions, which makes custom policy a whole heap easier | 16:50 |
| lbragstad | sure | 16:50 |
| lbragstad | but - you can't use a project-admin token to list all instances/volumes in the deployment, right | 16:50 |
| lbragstad | and you can't use system-admin either | 16:51 |
| johnthetubaguy[m] | that is the question I guess, and dansmith and I were chatting about that exact problem earlier | 16:51 |
| johnthetubaguy[m] | I think we just moved to checking for system admin to list all instances, but without checking the scope in rule | 16:51 |
| johnthetubaguy[m] | which means in step 1, any project admin can do it | 16:52 |
| johnthetubaguy[m] | this is clearly a bit broken, but its still a step forward (I think) | 16:52 |
| dansmith | johnthetubaguy[m]: I just replied on that | 16:52 |
| lbragstad | maybe i'm getting my wires crossed | 16:52 |
| lbragstad | i thought we didn't want to let system users do things on project-owned resources | 16:53 |
| dansmith | johnthetubaguy[m]: unrelated are you seeing private messages with your weird irc client? I've pinged you a couple times privately without response, but see you active here | 16:53 |
| lbragstad | that was framed as kinda like the point of no return | 16:53 |
| dansmith | johnthetubaguy[m]: also fine if you're just ignoring me, but just let me know :P | 16:53 |
| johnthetubaguy[m] | just went to read that (my email filters are way broken, oops) | 16:54 |
| johnthetubaguy[m] | ah, doh, I see your messages now | 16:55 |
| dansmith | ghosting me like a crazy online dating person... I get it :P | 16:55 |
| johnthetubaguy[m] | lol | 16:56 |
| johnthetubaguy[m] | I guess its a "feature" of this client | 16:56 |
| dansmith | "AI detected you probably don't want to hear from dansmith, he's creepy" | 16:56 |
| johnthetubaguy[m] | lbragstad: its probably me getting confused | 16:56 |
| lbragstad | well - the migration plan in general isn't trivial :) | 16:57 |
| johnthetubaguy[m] | I think I am slowing starting to agree with rosmaita | 16:58 |
| lbragstad | but i thought the intent was to keep system reserved for system-specific resources | 16:58 |
| lbragstad | meaning we can't overload it for listing all instances in the deployment (something that operators can currently do today) | 16:58 |
| lbragstad | based on the meetings we've been having - i thought we were going to try and solve that problem with domain role assignments | 16:59 |
| lbragstad | and then you would call nova with a domain-scoped token and it would filter the instances for you based on the domain id of the projects that own each instnace | 16:59 |
| rosmaita | yes, that is my understanding of what the plan is | 17:02 |
| lbragstad | so - in my mind, i think we have three options? | 17:09 |
| lbragstad | 1. add the domain admin persona as a goal for phase 1 | 17:09 |
| lbragstad | 2. add the domain admin persona as a goal for phase 2 | 17:10 |
| lbragstad | 3. implement domain admin in the client for phase 1 | 17:10 |
| lbragstad | #1 increases the work each services needs to do in phase 1 | 17:10 |
| lbragstad | #2 means we have a gap between yoga and z where an operator can't list all instances in a deployment in a single request | 17:11 |
| lbragstad | #3 increases the work for phase 1, but the implementation is limited to the client | 17:11 |
| rosmaita | so for #3, is the idea that the client will take a domain token, find all the projects in it, and then do a "list volumes" for all those projects as one response? | 17:15 |
| lbragstad | yeah - pretty much | 17:15 |
| lbragstad | it also assumes the domain user has an inherited role assignment from the domain to each project within the domain | 17:16 |
| rosmaita | paging will be a nightmare, but i guess it's ok (since i personally am not implementing it) | 17:17 |
| rosmaita | actually, paging might not be too bad | 17:17 |
| lbragstad | i do think we already have a lot targeted for phase 1 | 17:20 |
| lbragstad | so #1 is my least favorite option because it does feel like scope creep, and we started rewriting this goal because it was already to big-bang-ish | 17:21 |
| rosmaita | i guess the impact of #2 is limited if (a) you are running yoga with enforce_scope=False and (b) the domain support is implemented early in Z | 17:29 |
| gmann | lbragstad: dansmith johnthetubaguy[m] rosmaita cannot we keep project admin to keep doing that until we have domain admin ? and say 'project admin can read all things for now which was case till now but not write on other project resource' | 17:30 |
| gmann | and once we have domain admin in Z or later then we extract this project admin doing everything within project only | 17:30 |
| lbragstad | so update 'detail:get_all_tenants': 'role:admin' | 17:31 |
| gmann | yeah | 17:31 |
| gmann | but with project acope | 17:31 |
| gmann | scope | 17:31 |
| lbragstad | scope_types = ['project'] | 17:31 |
| gmann | yes | 17:31 |
| gmann | so we are not changing anything what is working now | 17:31 |
| lbragstad | sure | 17:31 |
| gmann | even with scope enable | 17:31 |
| lbragstad | so - that's option #4 | 17:31 |
| lbragstad | and that would only be applicable to listing all instances and volumes, right? | 17:32 |
| gmann | yes | 17:32 |
| rosmaita | and backups and snapshots and ... | 17:32 |
| lbragstad | lol | 17:32 |
| gmann | everything else like reboot, resize etc write operation will be within project only | 17:33 |
| * lbragstad starts falling down the slippery slope | 17:33 | |
| gmann | I mean 'list all project resources'. | 17:33 |
| gmann | what all resource project admin can do today for all that they can continue doing until domain admin | 17:33 |
| lbragstad | yeah - so i think we need to know what that list would be | 17:33 |
| rosmaita | we discussed this at the PTG (the cinder team, i mean) and we decided that it's better to not have the functionality than to hack it like this | 17:33 |
| lbragstad | and we could call it out in the goal | 17:33 |
| gmann | basically one polciuy 'all-tenant' one | 17:33 |
| gmann | rosmaita: but we are not changing anything on 'all-tenant' things so no hack right? | 17:34 |
| gmann | its just this new feature we will do in Z but we are not breaking you | 17:34 |
| rosmaita | well, the persona is supposed to be project-specific and not cross project boundaries | 17:34 |
| gmann | yeah, but without 'all-tenant list' case which we can docuemnt | 17:35 |
| rosmaita | yeah, maybe i am being too inflexible | 17:36 |
| gmann | and honestly saying 'all_tenants' things are already bad UX so keeping it as it for one more cycle would not harm anything | 17:36 |
| lbragstad | 5. remove --all-tenants | 17:36 |
| gmann | especially when admin need to get other project resource with all_tenant=1 and tenant_id | 17:36 |
| gmann | dansmith: RE: meeting, yeah I am thinking to have if other 5 TC are available. may be short one. which seems yes by seeing 'Absence section ' in https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions | 17:40 |
| jungleboyj | gmann: Thursday is Thanksgiving Holiday in the US so there probably won't be a lot of people in the US joining. | 17:44 |
| johnthetubaguy[m] | gmann: yeah, project admin seems OK for now, this is a cross-project case for project admin, but its not a system resource, so its the best step 1 case | 17:44 |
| lbragstad | ok - so we'd have to do that for instance, volumes, snapshots, backups, and ....? | 17:45 |
| gmann | lbragstad: I hope those are all, not sure if neutron has any such policy (slaweq ?) | 17:46 |
| johnthetubaguy[m] | well today its a project admin, on the old defaults | 17:46 |
| lbragstad | i think it's admin or owner? | 17:46 |
| lbragstad | so it might just be checking role:admin | 17:46 |
| lbragstad | it might not even be checking if there is a project associated to that role | 17:47 |
| lbragstad | or that it's a project-scoped token, rather | 17:47 |
| johnthetubaguy[m] | yeah, correct, role:admin check only | 17:47 |
| fungi | if i'm counting correctly, the tc can still achieve >50% attendance even if all usa-based members are absent | 17:47 |
| johnthetubaguy[m] | but it was a project token | 17:47 |
| gmann | johnthetubaguy[m]: lbragstad yes, its admin only. project owner cannot get other project instance. we return only their instance without any error | 17:48 |
| johnthetubaguy[m] | I am mixing things up there, sorry, I was meaning a project scoped token (currently) with a check to see if it has role admin | 17:48 |
| fungi | "For a meeting to be actually held, at least half of the members need to be present" https://governance.openstack.org/tc/reference/charter.html#meeting | 17:50 |
| fungi | so that still seems achievable | 17:50 |
| gmann | johnthetubaguy[m]: in current policy, it is system reader + deprecated policy admin | 17:50 |
| johnthetubaguy[m] | lbragstad: to your list above, I think I like option 2, but in the mean time let any project admin list all instances/volumes/project (rather than require system admin). | 17:50 |
| gmann | johnthetubaguy[m]: so old one which are in use is admin (legacy one) | 17:51 |
| johnthetubaguy[m] | gmann: I am thinking post dan's patch, sorry, that is adding to the confusion | 17:51 |
| gmann | ohk | 17:51 |
| fungi | though if all the current usa-based members and at least one other member don't attend, then there's insufficient quorum to hold the meeting (only 44% in attendance) | 17:51 |
| lbragstad | gmann https://review.opendev.org/c/openstack/nova/+/816206/7/nova/policies/servers.py#55 | 17:52 |
| gmann | johnthetubaguy[m]: and with option 2 , keep project admin list all tenant resource right? | 17:52 |
| lbragstad | option 2 would remove the ability for a project-admin to list all instances | 17:53 |
| gmann | lbragstad: +1, that seems right to be and do domain-admin in Z. which is your option 2 | 17:53 |
| gmann | lbragstad: humm | 17:53 |
| lbragstad | if enforce_scope = True and if they're using the new defaults | 17:53 |
| lbragstad | i'm thinking about the people that have been wanting to use this stuff forever | 17:53 |
| lbragstad | and if we can give them something useful in Yoga | 17:53 |
| lbragstad | they will deploy with enforce_scope = True and the new defaults | 17:54 |
| rosmaita | off topic, but could a domain-reader make this request? (doesn't have to be admin) | 17:54 |
| johnthetubaguy[m] | well, the thing is, with no scope checking, we can put anything in that scope, we are just checking the role, so making it project seems the "simplest" approach, but I can see good arguments for domain and system also | 17:54 |
| lbragstad | rosmaita yes | 17:54 |
| rosmaita | ok | 17:54 |
| lbragstad | using domain seems more "correct" to me | 17:54 |
| lbragstad | removing time lines and capacity constraints | 17:55 |
| johnthetubaguy[m] | although, if we allow no scope checking, if we are not careful, project reader can list all servers, so I think we need to avoid that | 17:55 |
| lbragstad | right | 17:55 |
| lbragstad | so - that's kinda why i'd advocate for domain-admin initially | 17:55 |
| lbragstad | until we can guarantee the old defaults are removed and enforce_scope = True | 17:56 |
| gmann | lbragstad: rosmaita I think we said domain admin as a special case where services not having domain scope. like nova does not map the projects under domains so domain admin is global admin for all-tenant case. domain reader might be confusing for whey domain reader list instance of other domain's project? | 17:56 |
| lbragstad | then i think it's safe to relax the domain-admin to doman-member and domain-reader | 17:56 |
| johnthetubaguy[m] | yeah, that is attractive, going for domain scope, although with no scope checking its the same, any project admin will be able to list servers across all project | 17:56 |
| lbragstad | which is what happens today | 17:56 |
| lbragstad | yeah | 17:56 |
| johnthetubaguy[m] | yeah, agreed | 17:56 |
| lbragstad | but- if we try to do that with reader initially | 17:56 |
| rosmaita | ok, i guess we have a consensus (more or less)? | 17:56 |
| lbragstad | anyone with the reader role on a project will pass that check when using the old defaults | 17:57 |
| lbragstad | so - i think it's important to say that domain-admin functionality is getting the foot in the door | 17:57 |
| gmann | yeah | 17:57 |
| lbragstad | and then once we know we're not dealing with the old broken checks anymore, we can relax it to domain-member and domain-reader | 17:57 |
| johnthetubaguy[m] | yeah, that could work | 17:57 |
| lbragstad | we have to do the same thing with system | 17:57 |
| gmann | yeah, system case is same | 17:58 |
| johnthetubaguy[m] | yeah, anything system needs to be admin to start with, +1 | 17:58 |
| gmann | we are not adding system reader/member now | 17:58 |
| gmann | *for now | 17:58 |
| lbragstad | but - doesn't require us to add *all* the system and domain personas to get this into operators hands | 17:58 |
| johnthetubaguy[m] | ... this means, step 1, project reader works, project member works, operators need to be in the correct project to do actions (until we do something fancy in the CLI with domain admin) | 17:59 |
| gmann | true and step by step things will make them easy to understand otherwise it can be 'hard to understand so i am not using it :)' | 17:59 |
| johnthetubaguy[m] | lbragstad: that is a crucial point, we need to not scope screep | 18:00 |
| johnthetubaguy[m] | s/screep/creep/ | 18:00 |
| gmann | so we are going with 'project admin doing all tenant list until Z and Z will have domain admin or so to do that' ? | 18:02 |
| johnthetubaguy[m] | maybe we said its domain admin, but given scope_check = false, project admin will be able to do it anyways? | 18:03 |
| lbragstad | ack - hoping into a meeting quick | 18:04 |
| lbragstad | i'll circle back | 18:04 |
| gmann | so adding domain admin in Yoga then? | 18:04 |
| johnthetubaguy[m] | maybe... although I am not sure its required given scope checks will be off, we need to make it good before scope checks go on | 18:05 |
| johnthetubaguy[m] | OK, its time for dad ops, I have to run, but I think we agree on a lot of that, but not quite everything yet | 18:07 |
| johnthetubaguy[m] | for me, step 1 is the key, and with no scope checks, essentially we are saying any type of admin, including any project admin, can list all servers | 18:09 |
| gmann | yeah that is ok but with scope checks and doping domain admin in Yoga seems more things to do especially when we already passed the m-1 of Yoga | 18:13 |
| gmann | My vote will be step 1 and for scope checks leave the all-tenant case for project admin and domain admin coming later.. | 18:14 |
| gmann | * and we will implement domain admin later in Z.. | 18:14 |
| lbragstad | ok - i'll write up gmann's version in the goal | 18:40 |
| lbragstad | and we can iterate on it there | 18:40 |
| gmann | sounds good to me. | 19:51 |
| opendevreview | Lance Bragstad proposed openstack/governance master: Rework the yoga secure RBAC community goal https://review.opendev.org/c/openstack/governance/+/815158 | 20:03 |
| lbragstad | gmann dansmith rosmaita johnthetubaguy[m] ^ | 20:04 |
| lbragstad | rough update | 20:04 |
| lbragstad | with the four different solutions and direction for Phase 1 | 20:04 |
| rosmaita | lbragstad: ack | 20:05 |
| dansmith | gmann: ack, I was thinking maybe it was more than half out but I guess not | 20:06 |
| dansmith | lbragstad: will try to catch up... crazy busy morning while that convo was going on | 20:06 |
| lbragstad | dansmith ack - no worries | 20:49 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!