You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently, every Helm Project Operator is forced to deploy both the controller that manages ProjectHelmCharts and the controller that manages hardening namespaces + creating project registration namespace all at once.
However, for users who want to configure multiple Helm Project Operators, they may want the definition of how Project Registration Namespaces are created and managed (i.e. hardenedNamespace.*, otherSystemProjectLabelValues, global.cattle.systemProjectId, global.cattle.projectLabel) to be managed independently of the configuration of the actual Helm Project Operator (e.g. valuesOverride, releaseRoleBindings.*, projectReleaseNamespaces.labelValues) to avoid multiple operators from trying to apply conflicting configurations.
Describe the solution you'd like
There should be a logical separation of controllers that are deployed such that they attempt to acquire locks independently and can be deployed standalone of each other.
Describe alternatives you've considered
Additional context
This would probably require a minor release since it's a major change in the way that the controllers are currently constructed that might require more rigorous QA and better understanding of how this would affect the user experience.
The text was updated successfully, but these errors were encountered:
For now, I don't think this should be tackled until we have a better understanding of other Project Operators that may be built based off of this project and their particular use cases.
Is your feature request related to a problem? Please describe.
Currently, every Helm Project Operator is forced to deploy both the controller that manages ProjectHelmCharts and the controller that manages hardening namespaces + creating project registration namespace all at once.
However, for users who want to configure multiple Helm Project Operators, they may want the definition of how Project Registration Namespaces are created and managed (i.e.
hardenedNamespace.*
,otherSystemProjectLabelValues
,global.cattle.systemProjectId
,global.cattle.projectLabel
) to be managed independently of the configuration of the actual Helm Project Operator (e.g.valuesOverride
,releaseRoleBindings.*
,projectReleaseNamespaces.labelValues
) to avoid multiple operators from trying to apply conflicting configurations.Describe the solution you'd like
There should be a logical separation of controllers that are deployed such that they attempt to acquire locks independently and can be deployed standalone of each other.
Describe alternatives you've considered
Additional context
This would probably require a minor release since it's a major change in the way that the controllers are currently constructed that might require more rigorous QA and better understanding of how this would affect the user experience.
The text was updated successfully, but these errors were encountered: