Closed toddbaert closed 4 months ago
@thisthat @bacherfl When I checked the output charts in https://github.com/open-feature/open-feature-operator/pull/647, the role-binding looked fine, but I never checked the role which is now more messed up :sweat_smile:
I will see how far I can get with this, but I wonder if we should change the patch to not be a delete and instead add the additional rules we need for ingress creation?
I started down the path of maintaining 2 roles and 2 rolebindings, one that controls the extra stuff we need when managerConfig.flagdResourceEnabled
is enabled, but after running through some proposed tutorials and dealing with this additional complexity, I honestly think the entire idea of managerConfig.flagdResourceEnabled
is not worth it. My reasoning is that it's easy to restrict the creation of flagd CR instances entirely (or instances with ingresses
) through many different tools and policies, since these are not created automatically by annotations. I just don't think we need to control them at the OFO install level.
Sorry @bacherfl for the wasted time here, since this was initially my idea. :pensive:
Helm installation is not working due to the recently added overlays removing rules from the
open-feature-operator-manager-role
. The operator is now not able to read openfeature.dev/* custom resources when installed with Helm: