| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-12 | |||
| 15:53:56 | sean-k-mooney | ill push what i have before the end of the day but might need more time to actully get test for all of them | |
| 15:54:44 | sean-k-mooney | dansmith: we proably should be blcoking all isntace actions | |
| 15:54:52 | sean-k-mooney | at least for now | |
| 15:54:58 | dansmith | sean-k-mooney: agreed | |
| 15:55:30 | dansmith | sean-k-mooney: kinda makes me wonder what the point of system-admin is in a lot of cases, if they can't shutdown or migrate instances | |
| 15:55:31 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Bump the Compute RPC API to version 6.0 https://review.opendev.org/c/openstack/nova/+/761452 | |
| 15:55:31 | sean-k-mooney | if we actully add support for isntace been own by a domain or somethin later then cool but for now even our logging assuems user and project id | |
| 15:55:35 | dansmith | I guess it's useful for aggregate type things | |
| 15:55:47 | bauzas | dansmith: just provided a new rev for your nits | |
| 15:56:05 | bauzas | and will work on a new rev for trying to only accept >=5.12 on Monday | |
| 15:56:08 | sean-k-mooney | dansmith: we might be able to support some of them but things like volumn attach might be weried | |
| 15:56:36 | dansmith | bauzas: yeah, was replying when I noticed... | |
| 15:56:44 | gibi | sean-k-mooney: ack | |
| 15:56:50 | sean-k-mooney | well actully not volumn atach snap shot is a better example | |
| 15:56:57 | dansmith | sean-k-mooney: yeah, I mean all of neutron would have to support this as well | |
| 15:57:05 | sean-k-mooney | if a system-admin creates a snapshot who would own it | |
| 15:57:22 | dansmith | sean-k-mooney: yep | |
| 15:57:37 | dansmith | sean-k-mooney: the slop becomes slippery quite fast | |
| 15:57:39 | dansmith | *slope | |
| 15:59:14 | sean-k-mooney | do we have a topic for the ptg for outstanding RBAC tasks | |
| 15:59:42 | sean-k-mooney | or do you think we will punt on domain users other thne fixing where it fails in Xena | |
| 15:59:54 | sean-k-mooney | or system for that mater | |
| 16:01:02 | dansmith | I dunno, I got the impression from lbragstad that domain users are not so widely used and maybe don't have a bright future | |
| 16:01:08 | sean-k-mooney | we would obviously need a spec to alter the api to support them but not sure we coudl do that without collaberating with other peoject too to line everything up | |
| 16:01:40 | sean-k-mooney | dansmith: i think only keystone has support for them today | |
| 16:01:41 | dansmith | yeah I kinda .. don't want to do that | |
| 16:02:01 | dansmith | coming up with a strategy for what to do if a sysadmin does an instance migrate is one thing, | |
| 16:02:04 | sean-k-mooney | but no one else | |
| 16:02:08 | gmann | yah domain is in keystone noly afaik | |
| 16:02:10 | lbragstad | keystone uses them - but it's unclear if other projects will fully adopt them | |
| 16:02:12 | dansmith | but making sysadmin able to create and snapshot instances, not so much | |
| 16:03:49 | sean-k-mooney | if i was to summerise. operation that create/consume reousces proably are not easy/desireable to support but other operations that change state of exising resouce may be ok | |
| 16:04:09 | sean-k-mooney | for system admin that is | |
| 16:04:49 | dansmith | sean-k-mooney: as a future goal, yeah.. as a short-term bug, probably need to just validate and reject anything related to instances | |
| 16:05:08 | dansmith | aggregates are fine, service actions are okay, etc | |
| 16:05:50 | sean-k-mooney | gmann:lbragstad: any of that ^ shocking or concerning to you ? | |
| 16:06:11 | sean-k-mooney | or was that also what ye were expecting. its more or less where my mind is at too | |
| 16:06:22 | lbragstad | sorry - catching up | |
| 16:06:30 | sean-k-mooney | not that i have spent that much time thinking about it | |
| 16:06:45 | lbragstad | ok - so domains | |
| 16:07:12 | lbragstad | since domains are containers of projects, i can see a case where calling GET /v2.0/servers with domain-scoped token would yield all servers across all projects within that domain... but, | |
| 16:07:39 | dansmith | sure | |
| 16:07:43 | lbragstad | you can also tell keystone to inherit a domain role assignment to all containing projects | |
| 16:07:45 | gmann | but system admin can also do same right? | |
| 16:07:49 | lbragstad | in which case, you do that and it works today | |
| 16:08:42 | lbragstad | and then nova doesn't have to fetch a hierarchy of projects from keystone - at least not right now | |
| 16:09:19 | dansmith | not sure how that will yield nova showing you all instances in your sub-projects, | |
| 16:09:24 | dansmith | because we would have to filter for multiples | |
| 16:09:41 | dansmith | we could do it (hence the sure) but I think we'd need the hierarchy | |
| 16:09:55 | lbragstad | right - i think so, too | |
| 16:10:01 | lbragstad | which nova doesn't support today | |
| 16:10:04 | lbragstad | afaict | |
| 16:10:05 | dansmith | right | |
| 16:10:14 | lbragstad | and that might just seem like a lot of extra processing | |
| 16:10:17 | dansmith | you said "works today" so wanted to clarify | |
| 16:10:19 | dansmith | yes | |
| 16:10:34 | sean-k-mooney | did we talk about keystone midelware portentaly being able to provide us with the set of projects | |
| 16:10:47 | lbragstad | what i meant there was that that same domain-admin could have an inherited role assignment on all containing project (this works today in keystone) | |
| 16:11:00 | lbragstad | allowing them to get project-scoped tokens for each project within their domain | |
| 16:11:01 | dansmith | domain admin is really a side thing though, right? unrelated to system_admin and no current focus on supporting it | |
| 16:11:39 | lbragstad | dansmith correct - imho domain-support is on the back-back-burner | |
| 16:11:50 | sean-k-mooney | so with keystone domains today you can have full admin on a subset of a cloud right and create falvors and such | |
| 16:11:52 | dansmith | ack, so back to sean-k-mooney's question about how to handle system admin | |
| 16:12:00 | gmann | yeah, i am also not so clear on use case of it | |
| 16:12:26 | lbragstad | so - so for system-scope, here are my thoughts | |
| 16:13:13 | lbragstad | i was open to leaving it up to the service to determine if they allow system-users to create resources within projects - but it would absolutely require an alternative method for supplying the project_id | |
| 16:13:24 | lbragstad | (e.g., like what glance does with the owner property in the request body) | |
| 16:13:53 | dansmith | I just don't think providing a project_id for every operation is reasonable | |
| 16:14:05 | dansmith | an *alternate* project_id I mean | |
| 16:14:13 | sean-k-mooney | neutorn added suport for project_id for networks and some other reseouce i htink | |
| 16:14:19 | lbragstad | my firm opinion is that i think it would be a bad idea if nova, for example, started using fake project ids to continue allowing system-administrators to create servers on behalf of other users | |
| 16:15:34 | gmann | yeah, we required that for create server on specific host use case but that could be achieving by opening the policy for get hypervisors and project admin or so do it | |
| 16:15:43 | gmann | lbragstad: is there any plan to support system-ids in system scope token instead of 'all' ? i remember that was original proposal for system scope. | |
| 16:15:43 | sean-k-mooney | i could maybe see this being done via midelwhere. where keystone alloed a system-admin toek to be create with a project_id | |
| 16:15:44 | lbragstad | or - if servers could be created under a project called 'system' or something liek that | |
| 16:15:47 | gmann | or that was dropped ? | |
| 16:15:49 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/rocky: [stable-only] gate: Pin CEPH_RELEASE to nautilus in LM hook https://review.opendev.org/c/openstack/nova/+/780286 | |
| 16:15:55 | sean-k-mooney | and then we would use that in nova as if it was a poject token | |
| 16:16:05 | lbragstad | gmann not dropped - just not enough time to implement it | |
| 16:16:08 | dansmith | maybe this is a dumb question, but if I have sysadmin powers and I want to create an instance for someone, can't I get a project token for that project before I create it? | |
| 16:16:10 | gmann | i see | |
| 16:16:15 | sean-k-mooney | lbragstad: basically allow one token type to issuee a lesser scoped token | |
| 16:16:17 | lbragstad | dansmith yes - exactly | |
| 16:16:29 | gmann | dansmith: yes | |
| 16:16:36 | gmann | same way for project user, | |
| 16:16:40 | dansmith | lbragstad: okay so system-scoped tokens need not be able to create resources directly right? | |
| 16:16:42 | lbragstad | if you're an admin - you have access to all of keystone's role assignment API | |
| 16:16:52 | gmann | if they want some system info in their operation then get system token or so.. | |
| 16:17:08 | sean-k-mooney | lbragstad: can you do it with out updateing asignemnt | |
| 16:17:28 | sean-k-mooney | lbragstad: e.g. can i use a system admin credential to issue a proejct scoped token directly | |
| 16:17:38 | sean-k-mooney | without assing a rule to myslef in the project | |
| 16:17:45 | lbragstad | dansmith correct - i think we'd really need to think through the ramifications of doing that consistently if we decided to open that up | |
| 16:17:46 | sean-k-mooney | *role | |
| 16:17:55 | lbragstad | sean-k-mooney no | |
| 16:18:08 | sean-k-mooney | so that would be a non invasive way to do it | |
| 16:18:23 | lbragstad | but it would bypass keystone's delegation mechanism | |
| 16:18:37 | sean-k-mooney | just adding proejct member and create a project toeknb does not feel like an improvment over what we have today | |
| 16:18:43 | dansmith | lbragstad: I would much rather make sure system admins (the people) can get a token to do what they need in a project, vs make every operation take a project (i.e. osc server stop --project $foo) | |
| 16:18:49 | lbragstad | which may have adverse side-effects on auditing | |
| 16:19:04 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: [stable-only] gate: Pin CEPH_RELEASE to nautilus in LM hook https://review.opendev.org/c/openstack/nova/+/780287 | |