environment-name as the default root of Hierarchical Namespace Controller (HNC)¶
- Status: accepted
- Deciders: arch meeting
- Date: 2022-09-29
Context and Problem Statement¶
As of apps v0.25 the HNC namespaces are available. Should we allow the root of the HNC to be configurable? What default value should it have?
- We want to reduce the number of tickets related to namespace creation.
- We want to make the operator life easier.
- HNC recommends against using default, as the user could edit the kubernetes svc in the default namespace.
- Hard-code the root of HNC to
- Hard-code the root of HNC to a value other than
- Allow the root of HNC to be configured, but provide a default value
Chosen options: Allow the root of Hierarchical Namespace to be configured, but provide a default value. The default value is the
environment-name. If a different value was previously used, then no migration is needed.
- We make the operator life easier by not having to handle namespace requests tickets
- Operator does not have to do the migration
- We offer flexibility to our customers in choosing if they want to keep existing non-HNC namespaces and from further on use the new HNC namspace to create new namspaces on their own.
- Increase customer autonomy
- Some snowflakiness will exist by keeping both the non-HNC and HNC namespaces
- Some customers might get confused at the beginning by not knowing which namespaces are HNC and which are non-HNC.
Recommendation to Operators¶
Do not use the "default" namespace as the name of the default root HNC namespace because the user could edit the kubernetes svc in the default namespace. Exclude the core and the AMS namespaces from HNC as we do not want those to be managed by HNC. Do not migrate customer to the new default root Hierarchical Namespace, but do inform the customers that they have the choice to migrate to it, if desired.