Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-10-16
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
12:29:14 sean-k-mooney good to know
12:29:29 pas-ha[m] down to specific API path and verb
12:29:45 sean-k-mooney personall i prefer using applciation creds even as a human
12:30:04 pas-ha[m] so like can give a get access to a specific server only (by uuid) and nothing else
12:30:26 sean-k-mooney that very powerful and useful to know indeed
12:30:59 pas-ha[m] switching the subject to scheduling, may I bring your attention to https://bugs.launchpad.net/nova/+bug/2076089 ? is there other way currently for an admin to boot an instance on a disabled compute host?
12:31:05 sean-k-mooney i knew i coudl scope by roles when using them but i have never looked at "access rules" before
12:31:31 sean-k-mooney pas-ha[m]: boot or spwan
12:31:44 pas-ha[m] boot
12:31:54 sean-k-mooney disableing computes is expictly for makign it imporssible to schdule a new worklaod
12:32:02 sean-k-mooney so https://bugs.launchpad.net/nova/+bug/2076089 is not valid
12:32:13 pas-ha[m] but it was working before 😕
12:32:18 sean-k-mooney the disables feature is descided to explcliy block that
12:32:23 pas-ha[m] and is a normal part of node onboarding
12:32:30 sean-k-mooney you can start existing vms on a disbale compute
12:32:51 pas-ha[m] how does one test a node w/o exposing it to the whole cloud?
12:33:24 sean-k-mooney in general you dont but in practice va a host aggreate and something like the tenant filter
12:33:25 pas-ha[m] short of adding a new az of course... that users still can see and attempt to boot on
12:33:53 sean-k-mooney you and do it in a way that users wont see using a number of methods

Earlier   Later