<@UE1LN7A22> I updated pulumi-kubernetes from 3.19...
# kubernetes
w
@gorgeous-egg-16927 I updated pulumi-kubernetes from 3.19.4 to 3.20.2 and enabled server side apply but now I'm seeing all the crds updating metadata on every update, similar to this issue that was fixed before ssa was available. 🤔
Also, I hit an issue with one of the resources:
Copy code
monitoring/cwagent-prometheus (kubernetes:yaml:ConfigGroup$kubernetes:apps/v1:Deployment)
error: 1 error occurred:
	* the Kubernetes API server reported that "monitoring/cwagent-prometheus" failed to fully initialize or become live: use `<http://pulumi.com/patchForce|pulumi.com/patchForce>` to override the conflict: Apply failed with 1 conflict: conflict with "pulumi-resource-kubernetes" using apps/v1: .spec.template.spec.containers[name="cloudwatch-agent"].resources.limits.cpu
So I added a
<http://pulumi.com/patchForce|pulumi.com/patchForce>: "true"
annotation to the deployment and it got past it. I then removed the annotation and it continued to work, so I'm wondering what happened here and if that's how you're supposed to use the annotation; i.e. temporarily apply it to fix the issue, or if it should be permanently applied??
g
I updated pulumi-kubernetes from 3.19.4 to 3.20.2 and enabled server side apply but now I’m seeing all the crds updating metadata on every update, similar to this issue that was fixed before ssa was available.
Hmm, could you open an issue with details? I didn’t change the CRD handling logic as part of that change, so I’m not sure what’s going on there.
For the
patchForce
question, that sounds like what I’d expect. If that option is set, the API call will use the “force” option to override any conflicts, but it’s not needed if there is no conflict. Whether you keep it on the resource after the initial conflict will depend on your use case.
w