I too am having this same issue. It is happening when I spawn an environment without declaring spot usage. Once I modify it to include spot declaration, thus modifying the end result manifest annotations, I get the same exact error. It also errors out on other sections that are modified, even with them added inside computed_fields.

I created computed_fields for spec.template.spec.tolerations, but not for metadata.annotations due to the documentation says I should be able to ignore adding that one.

│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to
│ module.k8-proxy.kubernetes_manifest.proxy-deployment, provider
│ "provider[\"registry.terraform.io/hashicorp/kubernetes\"]" produced an
│ unexpected new value: .object.spec.template.spec.tolerations: was null, but
│ now
│ cty.ListVal([]cty.Value{cty.ObjectVal(map[string]cty.Value{"effect":cty.StringVal("NoSchedule"),
│ "key":cty.StringVal("cloud.google.com/gke-spot"),
│ "operator":cty.StringVal("Equal"),
│ "tolerationSeconds":cty.NullVal(cty.Number),
│ "value":cty.StringVal("true")})}).
│
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.

Versions of providers and CLI used:

- hashicorp/google-beta: v4.8.0
- hashicorp/kubernetes: v2.12.1
- Terraform: v1.2.2

I created computed_fields for spec.template.spec.tolerations, but not for metadata.annotations due to the documentation says I should be able to ignore adding that one.

The documentation says that the default is ["metadata.labels", "metadata.annotations"]. If you set computed_fields yourself, you need to list those if you want them.

Unfortunately the docs are not as clear as they could be about this, but the part I've bolded below makes it clear:

IMPORTANT: By default, metadata.labels and metadata.annotations are already included in the list. You don't have to set them explicitly in the computed_fields list. To turn off these defaults, set the value of computed_fields to an empty list or a concrete list of other fields. For example computed_fields = [].

You've set it to a concrete list of other fields, so the defaults are overridden, and you need to include them explicitly if you want them.

I am having the same issue as @thomas-riccardi - regardless if I omit computed_fields compltely, or if I set it to computed_fields = ["metadata.annotations","metadata.labels"], change in annotation makes Terraform throw errors at me.

I don't know if you have to be more specific to avoid it from raising, but I changed to

    "metadata.labels",
    "metadata.annotations",
    "metadata.annotations[\"deprecated.daemonset.template.generation\"]",

and it passed

EDIT

OK, it seems that did not fix it. It just happens that we apply the changes twice and the second time it does not fail. (?)

Is there any resolution for this? This bug means you essentially cannot use a replicaset with this provider, which seems... very wrong. I have tried the above workarounds, which according to the documentation should work, but not having any luck.

example:

When applying changes to │ module.deployments["(redacted)"].kubernetes_manifest.kubernetes-manifest["templates/deployment.yaml"], provider │ "provider[\"registry.terraform.io/hashicorp/kubernetes\"]" produced an unexpected new value: │ .object.metadata.annotations["deployment.kubernetes.io/revision"]: was cty.StringVal("10"), but now cty.StringVal("11").

my manifest computed_fields looks like this:

computed_fields = ["spec.ingress", "metadata", "metadata.annotations", "metadata.annotations[\"deployment. kubernetes.io/revision\"]"]

I have tried without the escaped quotes, but it will not plan because it expects a string. It seems like it is interpreting the escaped sequences literally, but I cannot get around this issue.

edit: my particular issue appears to be a bug with a wait block with rollout = true set for the deployment. When I remove this block, I do not see this behavior anymore, no matter what computed_fields is set to.

I confirm, we do experience exactly the same issue as @rigman24 - when wait { rollout = true } is provided for a Daemonset in the kubernetes_manifest resource, the apply of the configuration consistently fail wit the above error that requires a retry for the error to disappear.

It's currently very incovenient to manage daemonsets using this resource and there are no many other options as the gavinbunney/kubectl provider is no more maintained...

EDIT: So I have troubleshooted further, and I'm experiencing the error even when I remove the wait block from the resource.

I plan to check if migrating the DaemonSet from kubernetes_manifest to kubernetes_daemon_set could address this issue.

I've tried to use kubernetes_daemon_set_v1 resource - it does not throw Error: Provider produced inconsistent result after apply error, but it does not respect wait_for_rollout = true and is always applied immediately, as you can read in #2092. It's a magic circle, there is no way how to correctly manage DaemonSets in kubernetes provider right now.