You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Provision a kubernetes_job resource, with spec.template.metadata.labels populated with some labels
Modify the labels in spec.template.metadata.labels
Generate a plan
Expected Behavior
The plan produced should show a replacement of the kubernetes_job resource
Actual Behavior
The plan produced an update of the kubernetes_job resource, and subsequently applying it silently errors (presumably, since modifying spec.template.metadata.labels via kubectl results in an error
Important Factoids
Notably, modifying spec.template.spec does correctly perform a replacement, so it seems like an oversight in the resource in detecting when to replace vs update.
This issue can be worked around by using Terraform's lifecycle block's replace_triggered_by. For example:
Disclaimer: above workaround is not fully tested, YMMV. We ended up setting up a replace_triggered_by on the job's namespace resource, since they have the same labels.
Affected Resource(s)
kubernetes_job
kubernetes_job_v1
Steps to Reproduce
kubernetes_job
resource, withspec.template.metadata.labels
populated with some labelsspec.template.metadata.labels
Expected Behavior
The plan produced should show a replacement of the
kubernetes_job
resourceActual Behavior
The plan produced an update of the
kubernetes_job
resource, and subsequently applying it silently errors (presumably, since modifyingspec.template.metadata.labels
viakubectl
results in an errorImportant Factoids
Notably, modifying
spec.template.spec
does correctly perform a replacement, so it seems like an oversight in the resource in detecting when to replace vs update.This issue can be worked around by using Terraform's lifecycle block's
replace_triggered_by
. For example:Disclaimer: above workaround is not fully tested, YMMV. We ended up setting up a
replace_triggered_by
on the job's namespace resource, since they have the same labels.References
Someone observed this behavior before on #1091 (comment)
Community Note
The text was updated successfully, but these errors were encountered: