| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-10-16 | |||
| 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. | |
| 15:13:05 | sean-k-mooney | flavor s shoudl nto eb managebale by end users | |
| 15:13:27 | admiyo | And images in glance was an issue that they addressed. | |
| 15:14:11 | admiyo | So you can see, it was an Openstack wide issue, and you DID address it. And it certainly affected Nova. | |
| 15:15:04 | admiyo | BTW, the original implementation was done by termie, the solution of having admin projects was also suggested by him. I was justtrying to keep things consistent with how the main projects viewed things. | |
| 16:11:15 | opendevreview | Amit Uniyal proposed openstack/nova stable/2024.1: Reproducer test for image property hw_architecture https://review.opendev.org/c/openstack/nova/+/932531 | |
| 16:11:16 | opendevreview | Amit Uniyal proposed openstack/nova stable/2024.1: Libvirt: updates resource provider trait list https://review.opendev.org/c/openstack/nova/+/932532 | |
| 16:11:56 | opendevreview | Amit Uniyal proposed openstack/nova stable/2023.2: Reproducer test for image property hw_architecture https://review.opendev.org/c/openstack/nova/+/932533 | |
| 16:11:57 | opendevreview | Amit Uniyal proposed openstack/nova stable/2023.2: Libvirt: updates resource provider trait list https://review.opendev.org/c/openstack/nova/+/932534 | |
| 16:13:07 | opendevreview | Amit Uniyal proposed openstack/nova stable/2023.1: Reproducer test for image property hw_architecture https://review.opendev.org/c/openstack/nova/+/932536 | |
| 16:13:08 | opendevreview | Amit Uniyal proposed openstack/nova stable/2023.1: Libvirt: updates resource provider trait list https://review.opendev.org/c/openstack/nova/+/932537 | |
| 17:46:26 | opendevreview | Merged openstack/placement master: Remove Python 3.8 support https://review.opendev.org/c/openstack/placement/+/925648 | |
| 18:44:34 | gmann | admiyo: we have not touched the admin role due to not breaking the users. and like sean-k-mooney mentioned project manager is something (going to be implemented in Nova soon) which can serve as higher authority than member/reader role within project | |
| 19:04:55 | opendevreview | Merged openstack/nova master: VMware: updates resource provider trait list https://review.opendev.org/c/openstack/nova/+/926522 | |
| 20:30:21 | admiyo | apart, I am trying to make sense of the landscape. | |
| 20:30:21 | admiyo | gmann, you could start by acking that there is a problem and not marking the bug as a woishlist item tagged will not fix. It is a real problem and requires a united effort across openstack to address. I can appreciate that the systems roles approach doesn't work for people. I had stepped back when the Keystone leadership pivoted to that approach instead of "is_admin_project" and now seeing that the other approach fell | |
| 20:32:57 | admiyo | If I understand correctly, you have taken the approach of "make it impossible to assign the role admin except to system wide admin users" which is a feature that was not in Keystone when I left the project, and which would have broken other projects at the time. I think it is still not correct, but it might be good-enough. | |
| 20:37:47 | sean-k-mooney[m] | admiyo: the pivort away form that happend many many years before the change in direction. the idea of a specal adming project was not how openstack worked before we started supporting python 3 | |
| 20:38:56 | sean-k-mooney[m] | admiyo: ill also note that you are taking a very agressive approach there in blaming people for a descision taht was made collectivily over the course of many years | |
| 20:39:04 | admiyo | sean-k-mooney[m], let me take a look at the Nova API policy enforcement to make sure I understand the approach. | |
| 20:39:29 | sean-k-mooney[m] | while i dan and gman all took part in the discusion the direction was not set by the nova comunity | |