Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-10-16
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
20:40:20 admiyo sean-k-mooney[m], I am aggressive on it, because it has been met with ignorance for a long time, and I put a lot of effort in to it. And because it was one of the reasons that the project was long term hurt in adoption. But I am going to do my due diligence now to see if I understand the state of it.
20:40:50 admiyo I did talk with the Keystone devs and there are aspects to this solution that they did not understand, and so I don't trust that the solution is in place yet.
20:44:50 gmann I agree that we might have solved all the cases for access control but seeing the back and forth approach for so many years, we are trying to mainly solve 1. project personas (mainly ready role and new one called project manager )2. better service to service interaction
20:45:02 gmann there is idea of global reader also but its spec not yet up
20:46:09 gmann and i think doing these in bit and pieces taking mostly asked personas as first step is the feasible solution otherwise we could have stuck on it for another 5 years
20:48:13 sean-k-mooney[m] most of the intiall work was completed in https://specs.openstack.org/openstack/nova-specs/specs/train/approved/policy-default-refresh.html in 2019
20:48:30 sean-k-mooney[m] we then had to rip out and redo a subset of that
20:48:36 gmann yeah
20:48:38 sean-k-mooney[m] mainly the systemscopted parts
20:48:58 sean-k-mooney[m] and since hten we have been focusing on the personas that operators were actully asking for
20:49:12 sean-k-mooney[m] the reader roles was the highest priorty
20:49:37 sean-k-mooney[m] then the servicer role gained impoartnace for CVE reasons and now we are working on the manager role
20:49:49 gmann exactly. for system scope, I will say we tried to sell this new feature to operators when they did not require it :)
20:49:55 sean-k-mooney[m] for that soped hiher privaldged user that is not global admin
20:50:51 gmann everyone mainly asked for reader role and we tried to give them system scoped concept also which made them confused and break
20:50:55 sean-k-mooney[m] but even before the work in train you could have had custom policy it just was not in tree so this has evovled alot over the last 10 years
20:51:28 gmann true, main idea is to make our default as close as what operator override to
20:51:47 gmann we cannot match each and every cases but match with the mostly used one
20:52:18 sean-k-mooney[m] which is always a blance between public cloud usecases and private cloud
20:52:30 admiyo You have put a lot of work in to this.
20:53:34 admiyo It is 7 years since I stepped away from the project, and you are still working on it.
20:53:34 sean-k-mooney[m] gmann has alot more then i as they have also been invovled in the tempest testing of this not just enabling it in one porject
20:54:08 sean-k-mooney[m] yep we littally impemetned project scopes released it and operators said no
20:54:17 gmann :) progress is slow I agree but If I count we have ~12 projects implemented the project personas reader role which is good
20:54:20 sean-k-mooney[m] so we had to rip it out as we had no path to enable it by defualt
20:54:36 admiyo And they implemented system scopes based on operator feedback.
20:54:46 gmann this cycle, I am going to make more progress on remaining projects and manager role in core services
20:56:08 admiyo It used to be possible to generate the default policy file from the code. I am assuming that is still the case, and that I need a proper tox set up to do so. As I recall, that was tox genpolicy?
20:56:11 sean-k-mooney[m] i belive nova,neutron,placement, ironic and maybe glance and cidner + obviously keystoen had system scope
20:56:24 sean-k-mooney[m] now it has been removed form all but keystone and ironic i think
20:56:50 gmann yes, genpolicy tox env
20:56:55 sean-k-mooney[m] that is still possible yes althoguh you dont need a policy file anymore
20:57:07 sean-k-mooney[m] you only need it if you want to change it
20:57:11 admiyo It just allows me to see what the actual policy enforcement is, though
20:57:20 sean-k-mooney[m] we now also use yaml instead of json for reasons
20:57:20 admiyo as opposed to crawling through all the apis.
20:57:34 admiyo I think comments were the primary driver
20:57:37 gmann yeah
20:58:35 sean-k-mooney[m] if you do want to look at the code its all in https://github.com/openstack/nova/tree/master/nova/policies

Earlier   Later