🐛 Fix the wait conditions issue in the kubernetes_manifest resource

[arybolovlev]

Description

This PR fixes an issue in the kubernetes_manifest manifest when it is used with the wait conditions. This happens because the provider works with the object that the Kubernetes cluster returns after creation and doesn't update the object(request a newer version) once the conditions are met. Because of that the initial object(the one that the provider receives right after the create call) ends up in the TF state and some attributes are not available for the reference. A good example here can be metadata.labels and metadata.annotations that controllers assign to the Kubernetes objects after their creation. metadata.labels and metadata.annotations are often used in the wait conditions and as an input for other resources to be created or outputs for further usage.

Changes:

• Move the wait condition code right after the resource creation to fail earlier in the case of any issue that occurs during the waiting time.
• Add read operation when the wait conditions are met successfully.

For example, the following code will be executed with the "Invalid index" error message:

resource "kubernetes_manifest" "this" {
  manifest = {
    apiVersion = "v1"
    kind       = "Secret"
    metadata = {
      name      = "this"
      namespace = "default"

      annotations = {
        "kubernetes.io/service-account.name" = "default"
      }
    }
    type = "kubernetes.io/service-account-token"
  }
  wait {
    fields = {
      "metadata.annotations[\"kubernetes.io/service-account.uid\"]" = "^.*$",
    }
  }

  timeouts {
    create = "10s"
  }
}

output "this" {
  value = kubernetes_manifest.this.object.metadata.annotations["kubernetes.io/service-account.uid"]
}

That happens because the annotation kubernetes.io/service-account.uid is not available right after the resource creation and added by a controller for some time(that is why the condition is used here). The second apply will be successful.

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:

$ go test -count=1 -tags acceptance -v ./manifest/test/acceptance/... -timeout 120m -run TestKubernetesManifest_WaitFields_Annotations

2023/07/03 17:23:03 Testing against Kubernetes API version: v1.26.6
=== RUN   TestKubernetesManifest_WaitFields_Annotations
2023-07-03T17:23:04.036+0200 [INFO]  [ApplyResourceChange][Wait] Waiting until ready...

2023-07-03T17:23:04.038+0200 [INFO]  [ApplyResourceChange][Wait] Done waiting.

--- PASS: TestKubernetesManifest_WaitFields_Annotations (1.05s)
PASS
ok  	github.com/hashicorp/terraform-provider-kubernetes/manifest/test/acceptance	1.867s

Release Note

Release note for CHANGELOG:

`resource/kubernetes_manifest`: fix an issue with the `kubernetes_manifest` resource, where an object fails to update correctly when employing wait conditions and thus some attributes are not available for the reference after creation.

References

Fix: #1957

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

[arybolovlev]

This change is not related to the fix directly, however, I found this useful to configure the cluster name for manual testing purposes while working on this issue.

[jrhouston]

Looks good, thanks for fixing this 🚀