Use 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?

Decision Drivers

  • 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.

Considered Options

  • Hard-code the root of HNC to default
  • Hard-code the root of HNC to a value other than default
  • Allow the root of HNC to be configured, but provide a default value

Decision Outcome

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.

Positive Consequences

  • 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

Negative Consequences

  • 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.