| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-10-16 | |||
| 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 | |
| 22:51:46 | sean-k-mooney[m] | liek biforst can | |
| 22:52:43 | sean-k-mooney[m] | so im just sad metal3 cant, when direct ironic or even ironci via nova can scale better | |
| 22:54:11 | JayF | sean-k-mooney[m]: it really can, I'm curious what the limitation is there | |
| 22:54:20 | JayF | sean-k-mooney[m]: oh, probably sqlite? | |
| 22:54:27 | JayF | if metal3 still uses sqlite by defaultt | |
| 22:55:47 | sean-k-mooney[m] | JayF: i think its ectd and how its monitoring the proress of the deployment | |
| 22:56:06 | JayF | oh, so *completely* outside of Ironic's pervue then | |
| 22:56:26 | JayF | and likely in a way that could be fixed (e.g. notifications->some consuming service which updates etcd via push instead of polling | |
| 22:56:34 | sean-k-mooney[m] | right ironic can scale more but the baremetal operator that is managing it cant keep up | |
| 22:56:49 | sean-k-mooney[m] | if you ask it to do 100 ndoes it will eventually catch up | |
| 22:57:40 | JayF | when onmetal was first being created; the principle engineer on our team would just drop 100 builds on us occassionally as a test | |
| 22:58:00 | JayF | that is actually the reason we redid the compute manager in ironic to do peer list, which we are just now ripping out | |
| 22:58:11 | JayF | because the old clusteredcomputemanager we used for ironic was so racey | |
| 23:00:57 | sean-k-mooney[m] | right but that predats palcement | |
| 23:01:28 | sean-k-mooney[m] | and like the admin roles in highnsigt we proably never would have done the peer list | |
| 23:02:24 | sean-k-mooney[m] | anyway i should calll it a day and go to sleep o/ | |
| 23:02:51 | JayF | o/ | |
| #openstack-nova - 2024-10-17 | |||
| 09:51:11 | pas-ha[m] | I failed to read the whole backlog of discussion on admin-ness etc, but some my thoughts: you want 'admin' or 'reader' or whatever only in one service? as admin create app creds with access rules limiting those to API of this service only. Done. | |
| 09:53:22 | pas-ha[m] | The actual problem I faced is that in all the services, 'adminness' means 2 things - admin API (possibility to perform certain action, like create a flavor') and admin for DB (possibility to read other projects data). And currently these are conflated. | |
| 09:55:53 | pas-ha[m] | This is why for now the only way to create a 'global reader' using project-scoped token is to create app creds with admin role and access rules scoped to GET APIs of all services only. This way all non-read request will be blocked by keystonemiddleware, but once the request reaches the actual service, it can do (read) whatever admin can. | |
| 09:57:56 | pas-ha[m] | What I also found suboptimal, is that in most services the actual 'personas' are defined as constants in code, not the rule: that can be easily overridden or extended by the cloud owner, requiring modification of many-many policy rules instead just several... | |
| 09:59:59 | pas-ha[m] | And I do agree that 'manager' will be a better solution instead of making a role do different things depending on the project it is assigned to. Leave 'admin' to be the admin of the whole cloud, period, and watch whom you give it carefully. Replace 'project admins' and even 'domain admins' with project and domain managers. Should make things more clear IMO. | |
| 12:26:31 | sean-k-mooney | pas-ha[m]: scoping accees base on the service has never been supported | |
| 12:26:52 | sean-k-mooney | it was discussed and delcared out of scope of the current srbac work | |
| 12:27:17 | sean-k-mooney | pas-ha[m]: part of the probelm there is keyston maps roles to user in a given project | |
| 12:27:51 | sean-k-mooney | btu to my konowladge there is not concept of a role assingment mapping between a user a a (service,project) pair | |
| 12:28:30 | sean-k-mooney | pas-ha[m]: so you cant express service (or endpoint) based access contol in the keystone data model without just crating many custom roles | |
| 12:28:38 | pas-ha[m] | yeah, I know, and I am fine with that, just pointing out how one can achieve that right now w/o any hacks, with APIs already available, and that is fine I guess | |
| 12:28:39 | sean-k-mooney | which was rejected for interop reasons | |
| 12:28:57 | pas-ha[m] | app creds + access rules = profit | |
| 12:29:10 | sean-k-mooney | oh you can scope app creds | |