| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-10-16 | |||
| 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 | |
| 22:51:03 | JayF | metal3 just doesn't expose any of our scaling features, really | |
| 22:51:39 | sean-k-mooney[m] | right but even with one conductor and no sharding i would expct ironci to be able to provision more then 25 servers at a time | |