Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Manifests drift detection #94

Open
olfway opened this issue Mar 4, 2021 · 3 comments
Open

Manifests drift detection #94

olfway opened this issue Mar 4, 2021 · 3 comments

Comments

@olfway
Copy link
Contributor

olfway commented Mar 4, 2021

It seems that kustomization_resource just uses kubectl.kubernetes.io/last-applied-configuration annotation and didn't check real manifests at all

Probably it documented somewhere but it was a big surprise for me

I updated argocd application via argocd web interface and kustomization_resource says there is no difference

But if I check with kustomize build | kubectl diff - I see the difference:

     targetRevision: HEAD
+  syncPolicy:
+    automated:
+      prune: true
+      selfHeal: true
@pst
Copy link
Member

pst commented Apr 10, 2021

Related: #89

@pp23 pp23 mentioned this issue Aug 4, 2021
Closed
pst added a commit that referenced this issue Nov 6, 2021
@pst
Stop relying on lastAppliedConfig annotation fix #94
36a3df8 
Currently, the provider relies on the lastAppliedConfig
annotation. The read method reads the annotation and stores
its value as the manifest in the Terraform state. This means,
Terraform only detects drift for Kubernetes resources managed
by the Kustomization provider, if there is a diff between
what's in the lastAppliedConfig annotation and what's in the
Terraform files.

Not all `kubectl` commands however update the annotation,
e.g. scale doesn't, so such drift is never corrected, even
if replicas was specified in the Terraform files.

Additionally, there are a number of issues (e.g. #136) that
although I have a hard time reproducing them reliably, I
strongly suspect to be a result of the current implementation
here too.

This change, stop relying on the annotation and instead uses
similar but reverse patching logic to the diff and upate
method to determine which attributes of the configuration in
the Terraform files / from YAML are different on the API
server. This is then stored in the state. And now drift is
determined between the values of all attributes set in
TF/YAML and what the API last returned for them.
pst added a commit that referenced this issue Nov 7, 2021
@pst
Stop relying on lastAppliedConfig annotation fix #94
74f7dc3 
Currently, the provider relies on the lastAppliedConfig
annotation. The read method reads the annotation and stores
its value as the manifest in the Terraform state. This means,
Terraform only detects drift for Kubernetes resources managed
by the Kustomization provider, if there is a diff between
what's in the lastAppliedConfig annotation and what's in the
Terraform files.

Not all `kubectl` commands however update the annotation,
e.g. scale doesn't, so such drift is never corrected, even
if replicas was specified in the Terraform files.

Additionally, there are a number of issues (e.g. #136) that
although I have a hard time reproducing them reliably, I
strongly suspect to be a result of the current implementation
here too.

This change, stop relying on the annotation and instead uses
similar but reverse patching logic to the diff and upate
method to determine which attributes of the configuration in
the Terraform files / from YAML are different on the API
server. This is then stored in the state. And now drift is
determined between the values of all attributes set in
TF/YAML and what the API last returned for them.
pst added a commit that referenced this issue Nov 7, 2021
@pst
Stop relying on lastAppliedConfig annotation fix #94
c0624c7 
Currently, the provider relies on the lastAppliedConfig
annotation. The read method reads the annotation and stores
its value as the manifest in the Terraform state. This means,
Terraform only detects drift for Kubernetes resources managed
by the Kustomization provider, if there is a diff between
what's in the lastAppliedConfig annotation and what's in the
Terraform files.

Not all `kubectl` commands however update the annotation,
e.g. scale doesn't, so such drift is never corrected, even
if replicas was specified in the Terraform files.

Additionally, there are a number of issues (e.g. #136) that
although I have a hard time reproducing them reliably, I
strongly suspect to be a result of the current implementation
here too.

This change, stop relying on the annotation and instead uses
similar but reverse patching logic to the diff and upate
method to determine which attributes of the configuration in
the Terraform files / from YAML are different on the API
server. This is then stored in the state. And now drift is
determined between the values of all attributes set in
TF/YAML and what the API last returned for them.
@nazarewk nazarewk mentioned this issue Feb 15, 2023
Open
@nazarewk
Copy link
Contributor

Is it a sensible approach to change kustomization_resource to kubernetes_manifest and wrapping manifest in yamldecode() to properly detect drift?

@nazarewk
Copy link
Contributor

Nevermind, the kubernetes_manifest seems to want to manage all the fields, including dynamic

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@olfway @pst @nazarewk