[Bug] SecurityContext settings override

[margreiext]

Describe the bug
SecurityContext settings for deployment in Kind Grafana override after grafana deployment successful creation

Version
App Version: 5.15.1
Chart Version: 4.8.0

To Reproduce
Steps to reproduce the behavior:

1. Apply Helm Chart for grafana operator
2. Describe Grafana kind via kubectl and grab SecurityContext settings (path: spec.deployment.spec.template.spec.securityContext)
3. Wait until Grafana deployment will be created
4. Describe again Grafana kind via kubectl and compare SecurityContext settings (path: spec.deployment.spec.template.spec.securityContext)

Expected behavior
SecurityContext settings for deployment(spec.deployment.spec.template.spec.securityContext) in Kind Grafana should not be override after Deployment creation.

Suspect component/Location where the bug might be occurring
Grafana operator logic in code responsible for reconciliation after deployment creation.
Probably it is updating Grafana kind resource base on deployment settings.

Screenshots
Before Deployment creation

After Deployment creation

Runtime

• OS: Linux
• Grafana Operator Version: 5.15.1
• Environment: Azure Kubernetes Service
• Deployment type: Helm via ArgoCD
• Other: Helm chart deployed via Argocd with App of Apps pattern

Additional context
The logic in grafana operator cause OutOfSync in ArgoCD Application level.
The initial sync of grafana operator chart when grafana Kind applied is successful with all SecurityContext settings applied as provided in values.
After Grafana Deployment creation SecurityContext changed(override) by settings provided in deployment. It cause that ArgoCD show differences for applied kind Grafana with comparison with version which stored in repository.

Attached values file
operator-values.txt

[pb82]

@margreiext are the security context settings changing after creating the deployment? Is you ArgoCD instance competing with the Operator here in updating those values?

[theSuess]

This happens as we update the resource with the default version if not set. This causes a re-serialization in which default or empty fields get omitted. To fix this, we'll need to use a PATCH request instead. I'll put together a PR for that soon