Use PatchForUpdate in Diff. #604
Conversation
The Kubernetes provider does not currently use a consistent method to compute the diffs and compute patches for update. The former only compares old inputs vs. new inputs using a simple JSON diff; the latter uses either a three-way strategic merge or a three-way JSON merge as necessary. These changes unify these approaches so that diffs are computed using the same three-way merge approach used during an update. In addition to being consistent, this approach also produces more correct results in the face of drift: if a Kubernetes resource is modified out-of-band such that a property value is changed or has been deleted with respect to the desired state, the new approach will detect that change where it would not have before.
| @@ -538,18 +538,35 @@ func (k *kubeProvider) Diff( | |||
| oldInputs.SetNamespace("") | |||
| newInputs.SetNamespace("") | |||
| } | |||
| if oldInputs.GroupVersionKind().Empty() { | |||
There was a problem hiding this comment.
If we have an empty old input set, the old input set will not have a GVK. openapi.PatchForResourceUpdate looks at the old input set to determine the GVK it will use to lookup patch meta. This ensures that the old inputs have a GVK that can be used by openapi.PatchForResourceUpdate.
I hope these don't cause any failures--I've run these (or some variant of them with the changes from #477) through the tests locally without issue, but CI may make a liar of me. |
As of today, the only scenario that should change is the case where a resource has had a property updated or deleted out-of-band, and those changes have been pulled in via a Once the changes in pulumi/pulumi#2849 land, this scenario will be simpler: because all diffs will be done in resource providers, the k8s provider will detect the out-of-band change without requiring that some other change has been made to resource inputs. This also affects the code in #477, as it gives us more flexibility with what to do in the case that a refreshed/imported resource is not annotated with its last applied configuration. |
The Kubernetes provider does not currently use a consistent method to
compute the diffs and compute patches for update. The former only
compares old inputs vs. new inputs using a simple JSON diff; the latter
uses either a three-way strategic merge or a three-way JSON merge as
necessary. These changes unify these approaches so that diffs are
computed using the same three-way merge approach used during an update.
In addition to being consistent, this approach also produces more
correct results in the face of drift: if a Kubernetes resource is
modified out-of-band such that a property value is changed or has been
deleted with respect to the desired state, the new approach will detect
that change where it would not have before.