Remove ArgoCD operation field to prevent perpetual diff

[corylevine]

Description

When using the kubernetes_manifest resource to manage an ArgoCD Application, it is possible for the status of Argo's sync operation to show up in the manifest when applying, but not during planning. This shows up under the top-level operation field, which is only present when an Argo sync operation is underway, potentially triggered by the Terraform apply.

This commit simply drops the operation field from manifests returned by the K8s API and thusly prevents it from being considered when diffing.

Acceptance tests

• [ ] Have you added an acceptance test for the functionality being added?
• [ ] Have you run the acceptance tests on this branch?

Output from acceptance testing:

$ make testacc TESTARGS='-run=TestAccXXX'

...

Release Note

Release note for CHANGELOG:

Prevent `operation` field in manifests from causing plan/apply diffs

References

Issue #2367

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

[hashicorp-cla-app[bot]]

All committers have signed the CLA.

[hashicorp-cla-app[bot]]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

_{Have you signed the CLA already but the status is still pending? Recheck it.}

[alexsomesan]

Whatever is causing the issue with the operation attribute of ArgoCD's Application CR will likely cause similar issues in similar conditions on other resources. We need to understand the root cause of it and address it generically.

This approach is not the way forward for this issue, because it introduces special handling of a specific CR (not even a core K8s resource). We designed the kubernetes_manifest resource with the express intent of handling all K8s object types through the same codepath and logic. We strive to keep it along that path and address issues in a generic manner.

Closing this, let's go back to the conversation in #2367 and find the root cause.