| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-10-16 | |||
| 13:31:23 | tkajinam | anyway this is rather a global issue and so far the "values" naming should help identifying the expected type | |
| 13:31:24 | tkajinam | yeah | |
| 13:34:30 | tkajinam | rpittau, I think that works. some of the people may be busy on Monday and Wednesday for tc discussion or cross project discussions but may be flexible on Tuesday or Thursday | |
| 13:34:47 | tkajinam | rpittau, though I'd defer the decision to bauzas | |
| 13:35:15 | rpittau | thanks, I chose thursday as for ironic is the less busy day | |
| 13:43:34 | opendevreview | Balazs Gibizer proposed openstack/nova master: Refactor obj_make_compatible to reduce complexity https://review.opendev.org/c/openstack/nova/+/928590 | |
| 13:43:35 | opendevreview | Balazs Gibizer proposed openstack/nova master: [libvirt]Support hw_vif_model = igb https://review.opendev.org/c/openstack/nova/+/928584 | |
| 13:43:35 | opendevreview | Balazs Gibizer proposed openstack/nova master: [ovo]Add igb value to hw_vif_model image property https://review.opendev.org/c/openstack/nova/+/928456 | |
| 13:43:36 | opendevreview | Balazs Gibizer proposed openstack/nova master: [doc]Developer doc about PCI and SRIOV testing https://review.opendev.org/c/openstack/nova/+/928834 | |
| 13:43:52 | opendevreview | Balazs Gibizer proposed openstack/nova master: Refactor obj_make_compatible to reduce complexity https://review.opendev.org/c/openstack/nova/+/928590 | |
| 13:43:53 | opendevreview | Balazs Gibizer proposed openstack/nova master: [libvirt]Support hw_vif_model = igb https://review.opendev.org/c/openstack/nova/+/928584 | |
| 13:43:53 | opendevreview | Balazs Gibizer proposed openstack/nova master: [ovo]Add igb value to hw_vif_model image property https://review.opendev.org/c/openstack/nova/+/928456 | |
| 13:43:54 | opendevreview | Balazs Gibizer proposed openstack/nova master: [doc]Developer doc about PCI and SRIOV testing https://review.opendev.org/c/openstack/nova/+/928834 | |
| 13:44:04 | gibi | tkajinam: fixed your comment :) ^^ | |
| 13:46:54 | tkajinam | gibi, thanks ! | |
| 13:56:35 | bauzas | rpittau: fair enough, we can do this at Thursday 13OOUTC | |
| 13:57:07 | bauzas | rpittau: adding it now in https://etherpad.opendev.org/p/nova-2025.1-ptg | |
| 13:57:12 | rpittau | bauzas: thanks, I'll update our schedule! | |
| 13:57:16 | bauzas | in our room or yours ? | |
| 13:57:35 | rpittau | we don;t have one booked at that time, maybe better yours | |
| 13:58:08 | bauzas | okay so please join the austin room :) | |
| 13:58:33 | rpittau | we will, thanks :) | |
| 13:58:45 | bauzas | rpittau: added it in https://etherpad.opendev.org/p/nova-2025.1-ptg#L69 | |
| 14:00:06 | rpittau | perfect, I've added it at https://etherpad.opendev.org/p/ironic-ptg-october-2024#L10 | |
| 14:15:03 | admiyo | to Nova. https://adam.younglogic.com/2017/05/fixing-bug-96869/ | |
| 14:15:03 | admiyo | sean-k-mooney, I see that you closed bug 698696 as won;t fix: https://bugs.launchpad.net/keystone/+bug/968696 I think that is a mistake. All role assignments are scoped. I had a proposal a few years back that addresses your concerns. Basically, for "global" actions that nova has scoped to a proejcct (due to history) you confirm that the project on the token is an "administrative" project. It requires minimal changes | |
| 14:19:30 | sean-k-mooney | admiyo: there is no such thing as a project scoped admin | |
| 14:20:05 | sean-k-mooney | admiyo: there is a governance document to descibe how roels shoudl work consitnatnly across all of openstack | |
| 14:20:26 | admiyo | sean-k-mooney, as of when? When Openstack started, that was all there was. It was a bug in the initial design, before Keystone was a project/ | |
| 14:20:30 | sean-k-mooney | the admin role is not scoped to a project based on the desgin agreed in yoga | |
| 14:20:58 | admiyo | And the reason why it has stuck around is that Nova scoped APIs to projects that needed the Aadmin role. It can't be fixed in openstack without being fixed in Nova | |
| 14:21:06 | admiyo | What I wrote up was the "hard" way | |
| 14:21:16 | admiyo | the even harder way was to fix all of the APIs in Nova | |
| 14:21:22 | sean-k-mooney | amorin: have you read https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html | |
| 14:21:34 | sean-k-mooney | amorin: you cant have a proejct scoped admin role in any project | |
| 14:21:37 | sean-k-mooney | its not just nova | |
| 14:21:57 | admiyo | We just killed the Admin role? | |
| 14:22:05 | sean-k-mooney | no | |
| 14:22:53 | sean-k-mooney | the admin role is defiend as a role that allows the bearer to performe admin operations on any service agaisnt any project | |
| 14:23:10 | sean-k-mooney | which is what it has alwasys ment | |
| 14:23:15 | admiyo | "we decided to postpone the scope implementation" | |
| 14:23:23 | admiyo | Heh....scope existed from the get go | |
| 14:23:36 | sean-k-mooney | not in anything other then keystone | |
| 14:23:52 | sean-k-mooney | we not only persponed it we removed it form almost every project that impmented it | |
| 14:24:18 | admiyo | Keystone split off from Nova. It was originally implemented there. The bug is Nova's original sin | |
| 14:24:34 | sean-k-mooney | admiyo: to be clear i was not makeign the deciosn to close it form a nova point of view | |
| 14:24:56 | admiyo | And the problem was that there WERE nova apis that required admin scoped to the project | |
| 14:24:57 | sean-k-mooney | as a comuntiy a collect dission was made not to go in that direction | |
| 14:25:10 | admiyo | so you HAD to split it up somehow. So you can fix it, and maybe it is fixed now | |
| 14:25:53 | sean-k-mooney | admiyo: have you read https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html or partipated in any of the discussion that have been taking place for the last 5 years on this topic | |
| 14:26:18 | admiyo | I got so burnt out by chasing this that I had to step away from Keystone. | |
| 14:26:36 | admiyo | And I have popped in periodically. The bug was still assigned to me for a while. | |
| 14:27:01 | admiyo | And I think it is ok to say that it is fixed if you cannot have a admin scoped project token | |
| 14:27:07 | sean-k-mooney | admiyo: when we explained to operator that they would not be able to do openstack service list --all-tenant with the proposed implemetion they said hell no | |
| 14:27:26 | admiyo | And there was a solution to that | |
| 14:27:45 | admiyo | That was why we had implied roles. | |
| 14:27:55 | sean-k-mooney | we still have implied roels | |
| 14:28:05 | sean-k-mooney | admin impiles member implies reader | |
| 14:28:12 | admiyo | I know. I wrote that implementation and I can see it has been maintained. | |
| 14:28:20 | sean-k-mooney | that does nto solve the problem when a servier is a proejct scoped resoucece | |
| 14:28:39 | admiyo | Yes it does.... | |
| 14:29:29 | sean-k-mooney | well in 5 years noone has been able to expalin how to make it owrk in a way that people can accpet and implemtnet | |
| 14:29:38 | admiyo | You need the appropriate role, but implied roles work down the hierarchy, So if I have the correct role on the parent proejct (or domain) it works for all projects underneath it. | |
| 14:29:58 | sean-k-mooney | sure | |
| 14:30:16 | sean-k-mooney | but we dont supprot domain scoped tokens and you cant have nested projects | |
| 14:30:22 | admiyo | And you could even do it on a domain, but it looks like they have made it work bettern | |
| 14:30:51 | sean-k-mooney | even if we did use the domain scopet token to list all the project you shoudl have acceess too that still means you cant see things across multiple domains | |
| 14:31:14 | admiyo | It used to work. | |
| 14:31:29 | admiyo | I think we called it the default domain.... | |
| 14:31:55 | sean-k-mooney | admiyo: i was just doing clean up of old bugs by the way | |
| 14:32:11 | sean-k-mooney | as far as i can tell what was being asked for in that bug is not compatible with the governance doc | |
| 14:32:33 | sean-k-mooney | admiyo: gmann: has been following srbac more closely then i | |
| 14:32:57 | sean-k-mooney | admiyo: but the only work i am aware of in this are is what descibe in that doc | |
| 14:33:06 | admiyo | It sounds like you have a fix in place. I think that is better to write up there than "won't fix." This was a deal breaker for giving people direct access to the API in a lot of cases, and lead to everyone putting APIs in front of OpenStack. I would love to see it closed properly. | |
| 14:33:10 | opendevreview | Merged openstack/placement master: Switch python version used for periodic jobs https://review.opendev.org/c/openstack/placement/+/932472 | |
| 14:33:46 | sean-k-mooney | admiyo: i really dont get the issue with acess to the apis | |
| 14:33:58 | sean-k-mooney | there are verly few things that actully need admin in nova | |
| 14:34:11 | admiyo | And do those HAVE to be on project tokens? | |
| 14:34:44 | sean-k-mooney | specificly creating flavors, managing compute servcices/host aggreates or things like live migration | |
| 14:34:50 | admiyo | I'll explein the issue after, but I am more interested in the solution, sounds like you have one | |
| 14:35:04 | sean-k-mooney | admiyo: yes if you want to create a service via nova you need to use a project scoped token | |
| 14:35:09 | admiyo | Right, and the resources you list there are not scoped to projects anymore? | |
| 14:35:44 | sean-k-mooney | they were system scoped and now they are project scoped again | |
| 14:36:08 | admiyo | but why are the "admin" then if admin is global role? | |
| 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 | |