| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-10-16 | |||
| 14:36:42 | sean-k-mooney | becuase flavors/hostaggated compute service are not somethign a normal user shoudl be able to modify | |
| 14:36:58 | sean-k-mooney | they are admin because only admins of the openstack cloud should be able to interact with them | |
| 14:37:19 | admiyo | but should a project admin be able to change flavors that are specific to a different project? | |
| 14:37:35 | sean-k-mooney | no | |
| 14:38:05 | sean-k-mooney | you are misussing that term based on the current agreed usage | |
| 14:38:24 | sean-k-mooney | a a use with an admin role is a global admin | |
| 14:38:40 | admiyo | can I have a project specific flavor ? | |
| 14:39:04 | sean-k-mooney | technially yes private flavor are a thing and only admins can create them on behayce fo end users | |
| 14:39:15 | sean-k-mooney | a normal user of a public cloud should not be allowed ot od that with the member role | |
| 14:40:04 | sean-k-mooney | admiyo: a new role that is seperat eform the curent heriacy was proposed if to have project scoped elevated access | |
| 14:40:07 | sean-k-mooney | https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#implement-support-for-project-manager-personas | |
| 14:40:11 | dansmith | flavors are also a lot more involved than they were in 2010 and require knowledge of the backend to some degree to set up in a lot of real-world cases, like knowing what hardware is available and in what configuration | |
| 14:40:14 | sean-k-mooney | its called the project manager role | |
| 14:40:40 | sean-k-mooney | that is part of phase 3 and we are in the midel of pahse 2 right now | |
| 14:41:00 | dansmith | and as sean-k-mooney has been saying, I think this is not nova-specific and also pretty much a sailed ship at this point | |
| 14:41:17 | admiyo | So it looks like you DO have a plan in place to fix the bug. It should not be closed as won't-fix | |
| 14:41:36 | sean-k-mooney | the bug is honestly invlid | |
| 14:42:06 | sean-k-mooney | we have specificly decied to not scope the admin role | |
| 14:42:16 | dansmith | agree | |
| 14:42:17 | admiyo | Well, no. It is not invalid. | |
| 14:42:23 | sean-k-mooney | we are keeping it as a global role and providing a new manager role | |
| 14:42:44 | sean-k-mooney | the manager role can be scoped to project or domains | |
| 14:42:53 | sean-k-mooney | when ever we implemet it | |
| 14:43:06 | admiyo | The admin role has been removed from being a project scoped role, that is fine. But do those APIs still look for the project ID on the token? That was the problem before. If nova has removed that restriction, then you have fixed it. | |
| 14:43:38 | sean-k-mooney | thats a diffent question. | |
| 14:43:39 | admiyo | Becuase other projects beside Nova "reqquired" if for day to day operations. It was a logicial contradiction | |
| 14:44:19 | sean-k-mooney | you realise that cinder or glance until recently reuiqred a proejct in the url | |
| 14:44:26 | sean-k-mooney | not just in the headers | |
| 14:44:27 | admiyo | Oh yes I do | |
| 14:45:15 | admiyo | that actually made certain things easier to do, so I understand why they did it. I am still not certain they were wrong, but having it consistent across all OpenStack was more important | |
| 14:45:19 | sean-k-mooney | to answer your question, weither or not we actuly need a project id depends on a few things, the policy file/default and if we are suign it for auiting | |
| 14:46:30 | ratailor | sean-k-mooney, gibi could you please review this patch https://review.opendev.org/c/openstack/nova/+/928933 and let me know why api-samples tests are failing, I assume something is missing, but not sure what ? I tried my best to find why its failing, but couldn't get any further. | |
| 14:47:05 | sean-k-mooney | if we look at the policy for managing flavor https://github.com/openstack/nova/blob/master/nova/policies/flavor_manage.py#L28 we use the base admin check https://github.com/openstack/nova/blob/master/nova/policies/base.py#L40 which does not check for the project id | |
| 14:47:46 | sean-k-mooney | admiyo: however much of our logging does expect a project id | |
| 14:47:56 | admiyo | policy file overrides are a fix, but not required, so I would say that case if OK. The real issue is the defaults. If the code requires a both a project ID and the Admin role, you have a problem. | |
| 14:48:36 | sean-k-mooney | admiyo: for context we moved them to be system scoped and undit that https://github.com/openstack/nova/commit/066e1e69d1394839a9f0bde4ca8c3a0db2d52396 | |
| 14:48:37 | admiyo | So how do you limit who can get the ADMIN role? | |
| 14:48:52 | sean-k-mooney | you do that via keystone | |
| 14:49:17 | sean-k-mooney | a keyston admin is needed to asing an admin role to a user on a project/domian | |
| 14:49:27 | admiyo | From my perspective, system scoped was a mistake. I understand why they did it (to make things more obvious) but it was fighting all of the services. | |
| 14:49:52 | sean-k-mooney | right which is why we went back to everyting in nova being project scoped again | |
| 14:50:50 | sean-k-mooney | admiyo: if you have a devstack you can proably jsut create a non project scoped token iwth the admin role and call nova to see what the behaivor is | |
| 14:50:59 | admiyo | What I had proposed was that we mark certain projects as ADMIN projects. Thus, if you wanted to be selective about what ADMINs could perform, say, a flavor modification, you put an additional check on those operations. But they still used project scoped tokens | |
| 14:51:33 | sean-k-mooney | admiyo: that not a nova dicussion | |
| 14:51:53 | admiyo | It waws. And it was accepted way-back-why byt the Nova PTL.... | |
| 14:51:59 | sean-k-mooney | if you give someone admin they have admin when you call nova or neutron | |
| 14:52:29 | sean-k-mooney | are you usign the term project to refer to openstack serivce or keystone pojects | |
| 14:52:55 | admiyo | No, I was specifically using it for projects. Because the APIs all required project scoped tokens | |
| 14:53:08 | admiyo | For keystone projects | |
| 14:53:11 | dansmith | admiyo: you seem to be missing a lot of context and community-wide discussion that happened in recent years... | |
| 14:53:23 | admiyo | and, I agreee, the name project was not the right one. | |
| 14:53:27 | dansmith | rehashing it with "it was agreed by the nova PTL in 2012" is not a very compelling argument in 2024 | |
| 14:54:05 | admiyo | it was in 2018, right before the Keystone PTL changed the direction and I rage quit. But the issue still stands that if it is broken in Nova it is broken everywhere | |
| 14:54:18 | admiyo | and the issue was that Admin was required on a project scoped token. | |
| 14:54:40 | admiyo | And elsewhere in openstack, that was required to do things that you would assume an end user could do | |
| 14:54:40 | sean-k-mooney | admiyo: for what its worth there was a discussion abou thaving a maping of roles ot service endpoints | |
| 14:55:23 | sean-k-mooney | admiyo: i.e. give someone admin on the neutron api but not on others. keystone did not want to do that | |
| 14:55:57 | admiyo | to be clear. I was never in support of service scoped tokens. I just stepped away from the discussion after a year of my life went in to gettin a nova acceptable solution....so all I am trying to do now is confirm that you do actually have a solution, and I am...55% convinced of that right now | |
| 14:56:41 | sean-k-mooney | admiyo: do you have an exampel of a call to noava that required admin on a diffent service | |
| 14:57:26 | admiyo | Back in the day it was stuff like add/remove userse from projects and grant role assignments. | |
| 14:57:43 | sean-k-mooney | which are all part of keystone | |
| 14:57:53 | admiyo | so in keystone to assign a user to a project, you HAD to have admin, becuase one of the roles you could grant them was Admin | |
| 14:57:56 | admiyo | and thus..... | |
| 14:58:12 | sean-k-mooney | right so the manager role is proposed to be used to do that | |
| 14:58:20 | sean-k-mooney | a porject manager would be able ot add a user to a project | |
| 14:58:50 | admiyo | TO be honest, I have not tracked what was done in Cinder or Glance ever since then. | |
| 14:58:51 | sean-k-mooney | a domain manager would be able to create proejcts and users in there domain | |
| 14:59:08 | admiyo | I know that kn heat you used to need it to clean up things that were wedged.... | |
| 14:59:45 | sean-k-mooney | again that just soudn like a bug | |
| 15:00:20 | admiyo | What you are saying is that a requirement in Nova dictated how all the other projects had to implement policy. | |
| 15:00:41 | sean-k-mooney | admiyo: no im not | |
| 15:00:51 | admiyo | And you then needed to audit and get agreement from all the other projects on how to fix it. | |
| 15:01:09 | sean-k-mooney | again please read that document | |
| 15:01:12 | admiyo | Yeah, you are. Because nova both required admin and that it be on a project scoped token | |
| 15:01:24 | sean-k-mooney | you are mising a lot of contenxt and missrepreenting what i have said | |
| 15:01:32 | admiyo | I have read it. And I get it, and you did get that agree ment, but I was not able to do that back in 2017 | |
| 15:02:04 | sean-k-mooney | to be clear neutron clinder glance and most other service had simeilr objects when they spoke to operatores about there needs | |
| 15:02:43 | admiyo | You might notice that glance, cinder and neutron all made efforts to fix the bug | |
| 15:02:46 | sean-k-mooney | admiyo: your framing the histroy as if nova was the one that pushed for this change when it was our user that push back | |
| 15:03:07 | sean-k-mooney | admiyo: so did we and then we reverted it based on teh compuntiy change of direction | |
| 15:03:41 | admiyo | Now go an look at my proposal again, and realize that it still addresses the operator concern, maintains backwards compat, and fixes the bug. | |
| 15:04:02 | admiyo | But all that is water under the bridge. It sounds like you do have a fix. | |
| 15:04:52 | admiyo | If that is the case, then don't mark the bug "won't fix." because that bug is the reason why end users did not get access to openstack APIs | |
| 15:05:21 | admiyo | the operators could not risk it, and they wrapped it with horrible things like CLoudForms and made the APIs operator only. | |
| 15:05:45 | opendevreview | Amit Uniyal proposed openstack/nova stable/2024.2: Reproducer test for image property hw_architecture https://review.opendev.org/c/openstack/nova/+/932521 | |
| 15:05:46 | opendevreview | Amit Uniyal proposed openstack/nova stable/2024.2: Libvirt: updates resource provider trait list https://review.opendev.org/c/openstack/nova/+/932522 | |
| 15:05:48 | admiyo | But it was not a wishlist item, and it should not be marked as won't fix | |
| 15:07:10 | admiyo | And by the way, we should never have had domains either. And we should have kept the term tennants instead of calling them projects. Mistakes of the past.... | |
| 15:08:06 | sean-k-mooney | admiyo: i can change it to invalid if you would liek. but what i was litrually trying ot convay by updating the bug was no one is working on changing the scope fo the admin role and its not inline wiht the projects direction | |
| 15:08:19 | sean-k-mooney | and by project i litraly mean openstack | |
| 15:09:18 | sean-k-mooney | admiyo: if you want to change the direciton you need to do that at the openstack level and change the grovernace resolution | |
| 15:10:11 | admiyo | Can you state that none of Novas APIs require Admin in order to perform operations that an end user needs to be able to do? To include project self maintainence like remove some resource where the owner has quit | |
| 15:10:46 | sean-k-mooney | as far as i am aware that has been true for at least 10 years | |
| 15:10:49 | sean-k-mooney | maybe more | |
| 15:10:51 | admiyo | That was not the case when we opened the bug, and it was a critical security issue. | |
| 15:11:22 | admiyo | Then you fixed it | |
| 15:11:43 | sean-k-mooney | in nova all end user creatable resocues are owned by teh project not the user with the sole excption of the ssh keypair | |
| 15:12:27 | admiyo | Yeah, let us avoid that rabbit hole | |
| 15:12:38 | sean-k-mooney | the reason is say at leat 10 years is i have worked on openstack since havana and i belive it was true for nova even then | |
| 15:12:52 | admiyo | I think that the issue I remember was flavors. | |