[Bug]: Uninstalling helm chart can cause issues with NGINX Plus mgmt config

[pdabelf5]

Version

edge

What Kubernetes platforms are you running on?

Kind

Steps to reproduce

When running NIC installed with NGINX plus and configured to deliver usage reports to a custom endpoint. If the helm chart is uninstalled the nginx instance can send a usage report to the default endpoint.

This occurs when the pod is marked by the Kubernetes cluster for deletion, Kubernetes then deletes the MGMT ConfigMap. NIC applies the default ConfigMap values and restarts NGINX. Eventually the pod is garbage collected and NIC/NGINX are stopped.

[pdabelf5]

running helm with --cascade foreground makes sure the Pod is garbage collected before the ConfigMap is removed and mitigates the issue

[pdabelf5]

Using OwnerReferences on the ConfigMap will also likely address the problem.

[pdabelf5]

Possible solution using helm hooks

[tstraley]

Helm Hooks are managed differently from other resources, and often lead to headaches over object ownership and lifecycle. I'd push for avoiding adding helm hooks to the chart if it can be avoided https://helm.sh/docs/topics/charts_hooks/#hook-resources-are-not-managed-with-corresponding-releases

[AlexFenlon]

Useful links in relation to OwnerReferences :

• https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/
• https://kubernetes.io/docs/concepts/overview/working-with-objects/finalizers/
• https://kubernetes.io/blog/2021/05/14/using-finalizers-to-control-deletion/

[AlexFenlon]

some investiagtion -
tried adding OwnerReference to the mgmtConfigMap for Pod, Replicaset or Configmap and nothing semes to work, it still gets reset to the default mgmt block just before the deployment is uninstalled via helm.

[shaun-nx]

@tstraley the team managed to get a fix in for this. Plan is to either v5.1.0 or v5.0.1 if we do a patch release before then.