Provider should possibly ignore additional label suffixes as well as kubernetes.io

[iamasmith]

Description

https://github.com/kubernetes-sigs/hierarchical-namespaces/blob/master/docs/user-guide/concepts.md#basic-labels

Describes labels that are used by Hierarchical Namespace Controller, each label, and there can be multiples of on a namespace depending on where it is within the hierarchy, uses a form like this.

service-1.tree.hnc.x-k8s.io/depth: 0
team-a.tree.hnc.x-k8s.io/depth: 1
division-x.tree.hnc.x-k8s.io/depth: 2

The label itself is named based on the namespace and it's position within the hierarchy with a /depth path to maintain the hierarchy (discussed in the link above). There are some other paths such as inherited-from also.

ignore_changes is limited as that cannot support wildcard patterns so it has been down to individual providers to provide scope for ignoring certain changes beyond and I believe the AWS provider does this for certain resources because of this limitation.

The precedent is that the kubernetes provider acknowledges kubernetes.io as a suffix that should be ignored.

I suggest that a list of ignored suffixes should be user configurable to cater for this scenario, alternatively giving consideration for k8s.io and x-k8s.io as defaults.

Potential Terraform Configuration

resource "kubernetes_namespace" "foo" {
  metadata {
    name = "foo"
  }
  managed_label_suffixes =  [ "x-k8s.io" ]
}

References

https://github.com/kubernetes-sigs/hierarchical-namespaces/blob/master/docs/user-guide/concepts.md#basic-labels

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[sheneska]

Hi @iamasmith, thank you for opening this issue.
A possible alternative solution to this would be to try using the ignore_annotations attribute.
Let us know if you have any questions!

[iamasmith]

@sheneska no, it doesn't really.

labels and annotations really need to be picked out individually as various controllers do different things and it's desirable to control them individually.

The nature of the labels, and it is labels in this case, are that they are variable based on namespace.