It is a common practice in helm charts to have different behavior based on if RBAC is enabled or not. This is typically just installing the RBAC roles only if RBAC is enabled. I think it would be a common ask in a k8s charm to get the RBAC status of the cluster to determine what to do during install. It can easily become a configuration option just like on helm, but it seems like it might be something that juju could know and provide to the charm as well. I just think about every config.yaml including some permutation of rbac, rbac-enabled, or enable-rbac and I feel like this wouldn’t be a desirable user experience. Do we know which way we will go on this?
Support for RBAC is under consideration for next cycle. How it is modelled is as yet unclear. To date, charms (cloud or k8s) don’t get to ask for information about the substrate on which they are being deployed as this breaks the Juju model. Do you have any concrete examples of what you wan to achieve?
Do you have any concrete examples of what you want to achieve?
Yes, I have a real concrete example. I’m trying to set up RBAC roles for a metallb charm. It requires certain roles and bindings, as do many k8s things, and I need some way to get this into the cluster. In a perfect world, I would know if RBAC was enabled on the k8s cluster and only apply these if it was, but I can also just create them regardless if necessary.