| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-10-16 | |||
| 22:25:11 | admiyo | That was one of the reasons I wrote that feature... | |
| 22:26:55 | sean-k-mooney[m] | we dont plan to remove admin by the way but we do plan to reduce what its used for as much as possibel by making it doable via manager or service depending on if a human should do it | |
| 22:27:16 | sean-k-mooney[m] | nova’s external evnets api should be service only | |
| 22:27:50 | sean-k-mooney[m] | because humans even the global adim should not send an event impersonating a openstack service | |
| 22:28:32 | JayF | honestly service scope is still the one thing that doesn't make a lot of sense to me | |
| 22:28:39 | JayF | how it's different than system scope in any context except keystone | |
| 22:29:05 | sean-k-mooney[m] | the diffent is scopes apply to the resouce not the token | |
| 22:29:27 | sean-k-mooney[m] | a port is owned by a project nto the system | |
| 22:29:44 | sean-k-mooney[m] | bindign a port to a host is a privaldaged action | |
| 22:29:46 | JayF | so if I take off my Ironic hat for a moment | |
| 22:29:55 | JayF | (since we have a history as admin-only I think we are exceptional a little) | |
| 22:29:58 | sean-k-mooney[m] | only servies shoudl be able to do that not humans | |
| 22:30:09 | JayF | essentially: a system-scoped admin shouldn't be able to do things to project-scoped items, generally | |
| 22:30:23 | sean-k-mooney[m] | correct | |
| 22:30:23 | JayF | only a service-scoped admin would, since service implies the ability to operate cross-project | |
| 22:30:32 | JayF | that makes so much sense why it doesn't make sense in Ironic then | |
| 22:30:44 | JayF | because we have to carry system-scope forward for everything due to $historical_baggage more or less | |
| 22:31:07 | JayF | at least until we're willing to require all new node creations to be scoped to a project, which will likely make a lot of our users unhappy | |
| 22:31:09 | sean-k-mooney[m] | another example form recent cves | |
| 22:31:13 | admiyo | JayF, that was my understanding, but the nova users seem to balk at that change. I am not certain it is alwyas wise tolisten to your users. I suspect in this case it will be good-enough. | |
| 22:31:26 | sean-k-mooney[m] | its safe for a normal user to detach a volume form a nova instance via the nova api | |
| 22:31:34 | sean-k-mooney[m] | its not safe to do that via cinders api | |
| 22:31:47 | sean-k-mooney[m] | so the cinder api requires the service role now | |
| 22:31:51 | admiyo | The problem is how role assignments are done in keystone. If you can do a role assignemnt, you can assign any role. | |
| 22:31:55 | sean-k-mooney[m] | but the nova detach volume api is member | |
| 22:31:59 | admiyo | So that needs to be fixed post haste | |
| 22:32:01 | JayF | oh no, this is venturing close to your favorite beef with the ironic model. Iceberg, dead ahead! Hard to port! LOL | |
| 22:32:37 | admiyo | I think that each API should actually have its own role, and then you use implied role assignments to link to the roles that users actually get | |
| 22:32:40 | sean-k-mooney[m] | well ironci is technically a service so it gets some leway because ye should be able to manage voluem in standalone mode | |
| 22:32:59 | admiyo | so ironic_volume could be a role, and admin implies ironic_volume | |
| 22:33:19 | JayF | that kills a big part of the operator value of the RBAC model | |
| 22:33:28 | admiyo | The issue is that Nova users are using project scoped tokens to do system wide operations. | |
| 22:33:35 | sean-k-mooney[m] | admiyo: it could btu we dont want to have service specific roles | |
| 22:33:41 | sean-k-mooney[m] | we want to have common personas | |
| 22:33:44 | JayF | I would never want, e.g., a reader role that didn't work for all services | |
| 22:33:50 | admiyo | personas are roles. | |
| 22:33:52 | sean-k-mooney[m] | that have a reasonable meeaning across all services | |
| 22:34:04 | JayF | sean-k-mooney[m]: ++ and that persona-based stuff is the value of the RBAC model to operators imho | |
| 22:34:05 | sean-k-mooney[m] | they are but personas are not service specific | |
| 22:34:15 | sean-k-mooney[m] | yep i agree | |
| 22:34:26 | JayF | the Ironic access granted to a nova user who just provisioned an instance is an A++ example of that tbh | |
| 22:34:27 | admiyo | i think in 3 levels | |
| 22:34:40 | JayF | a great example of how we carry the idea of that persona cross-project now in ways we didn't before | |
| 22:34:54 | sean-k-mooney[m] | the fact that you dont need ot give peopel createor on barbican and stack_operator? on heat and just use member was a big win | |
| 22:35:19 | admiyo | implied roles | |
| 22:35:38 | admiyo | reader implies nova_reader | |
| 22:35:46 | admiyo | or something .... | |
| 22:35:52 | sean-k-mooney[m] | we dont want role explsoiton or the imped roels to depend on which service are deployed | |
| 22:36:38 | sean-k-mooney[m] | having sepcific roels that are common across all clouds was part of the interop story | |
| 22:36:54 | admiyo | ah the old explosion argyument | |
| 22:37:07 | sean-k-mooney[m] | so instead of having nova_reader and ironic_reader we have jsut reader which works the same for each proejct | |
| 22:37:18 | admiyo | yeah, that is fine for somethings. | |
| 22:37:51 | admiyo | I think 3 levles: top level persona. bottom level resource. Middle level workflow | |
| 22:38:05 | JayF | Part of what I like about the policy model is that if you need more specific things than that, you can self-serve. It allows us flexibility without making our users get bombarded with a ton of information up front (e.g. the role explosion). | |
| 22:38:42 | admiyo | Execpt that the largest deployer, Red Hat, does not allow policy customization. | |
| 22:39:02 | JayF | I don't work there, I'm an OpenStack upstream contributor :) | |
| 22:39:11 | JayF | find someone with a red hat to complain to about red hat policies :) | |
| 22:39:17 | admiyo | I don;t work there anymore either. Because of things like this.... | |
| 22:39:26 | sean-k-mooney[m] | we dont allow it by defualt because we cant reasonably test it. | |
| 22:39:41 | sean-k-mooney[m] | i work there and we allow people to use it under a supprot excption | |
| 22:39:44 | admiyo | And that is because we mix too many things into policy enforcement | |
| 22:39:55 | JayF | admiyo: I don't speak for RH, but I assume like all things with enterprise software "not supported" means "ask us how much it'd cost" :D | |
| 22:39:59 | sean-k-mooney[m] | that basicallly say fi you want to diveragne and it breaks thats not covered by our support | |
| 22:40:20 | admiyo | Right, which is another way of saying "you can'tdo that" | |
| 22:40:34 | admiyo | and that is due to the existing mechanisms being too limited. | |
| 22:40:39 | sean-k-mooney[m] | i will nether confirm or deniy that we added a tripleo flag to generate the cutome role for a cutomer in a testable way :) | |
| 22:41:03 | JayF | what's tripleo? ;) | |
| 22:41:11 | admiyo | The best thing to come out of TripleO was the Owl T Shirt | |
| 22:41:18 | admiyo | openstack on openstack. OOO | |
| 22:41:27 | JayF | the best thing to come outta tripleo was ironic :D | |
| 22:41:36 | sean-k-mooney[m] | lol | |
| 22:41:37 | admiyo | ironic predated TripleO | |
| 22:41:40 | sean-k-mooney[m] | ironic predates it | |
| 22:41:58 | JayF | I didn't realize that, and bluntly, based on the community when I joined up with it in icehouse, the community was laser-focused on tripleo needs | |
| 22:41:59 | sean-k-mooney[m] | it was nova baremental and then ironci granduated before tripleo | |
| 22:42:13 | JayF | so I assumed it was always a tripleo-y service | |
| 22:42:26 | sean-k-mooney[m] | nope | |
| 22:42:54 | sean-k-mooney[m] | my prefered way to use it is via bifrost/kolla-ansible to be honett | |
| 22:42:59 | sean-k-mooney[m] | *honest | |
| 22:43:05 | sean-k-mooney[m] | keep it simple and debugablle | |
| 22:43:10 | admiyo | Yeah, Ironic was first done as an extension to Nova, and then it split out as the code was different enough...If I recall the process correctly | |
| 22:43:23 | admiyo | Yeah, bifrost is a good thing. | |
| 22:43:23 | sean-k-mooney[m] | it was the nova baremental driver | |
| 22:43:28 | admiyo | Right | |
| 22:43:49 | JayF | I knew about nova-bm, just didn't realize it was in use outside of tripleo use cases | |
| 22:44:02 | JayF | I did work on a cloud at $prev_purple_employer that I believe used that driver at some point though | |
| 22:46:07 | sean-k-mooney[m] | admiyo: redhat has replaced tripleo with a set of golang operators to deploy oepsntack as an applciation on openshift now | |
| 22:46:21 | admiyo | https://bugs.launchpad.net/keystone/+bug/1284922 is probably a better way to express the problem now | |
| 22:46:55 | admiyo | And openshift uses Ironic under the covers. | |
| 22:47:26 | admiyo | So we are finally at the "sandwich" | |
| 22:47:39 | admiyo | kube at the bottom. openstack in the middle. Kube at the top | |
| 22:48:50 | JayF | admiyo: also metal3 is secretly Ironic too :) | |
| 22:49:12 | JayF | admiyo: it's pretty funny how everyone is slowly realizing hardware is a pain and just integrating with us instead of building it out from scratch lol | |
| 22:49:28 | sean-k-mooney[m] | admiyo: yep we support deploy openshift on openstack which is istelf on a differnet openshift which uses ironci via metal3 to deploy the openshift 0’s workers | |
| 22:49:51 | JayF | you must pay architects by the layer over there :P | |
| 22:50:11 | JayF | each time we add an abstraction layer, a sales engineer gets their wings? | |
| 22:50:16 | sean-k-mooney[m] | JayF: the thing that makes me sad about metal3 is it limits the scalablity of ironic because the operator cant keep up | |
| 22:50:19 | JayF | (/s obviously) | |
| 22:50:45 | JayF | sean-k-mooney[m]: What I hear you say is that OpenStack is more scalable than K8s CAPI, nice to hear /s | |
| 22:50:50 | sean-k-mooney[m] | im sure there are ways to fix it but i belive they were having to do batches for 25 phsyical hosts when scaling out | |