Question about

pulumi up --refresh

: can anyone describe what

--refresh

does or point me to some documentation that explains it? The description in the CLI documentation isn't particularly detailed:

Refresh the state of the stack's resources before this update

I keep running into situations where I need to use the

--refresh

option with

pulumi up

or the updates are not applied correctly and the all of my Deployment resources are nonexistent after the stack is updated. I'm trying to understand why, when I need to to use

--refresh

, and whether I should always default to using

--refresh

when applying stack updates with

pulumi up

.

refresh

reads the object’s state from the cluster and updates pulumi’s state to reflect any changes. in general this isn’t needed if the object is only managed by pulumi, but if you have other operators acting on it (or if you’ve made manual changes) it can be useful.

Interesting. I'm running into two issues, which I suspect are related to what you mentioned about state being managed by pulumi: 1. Having to use

refresh

to not see errors such as "unable to get cluster state". 2. Having to set

"<http://pulumi.com/patchForce|pulumi.com/patchForce>": "true"

on the Deployment resources. Otherwise, I'm seeing `Server-Side Apply field conflict detected`for the annotations I'm updating on my Deployment resources. From my POV, I'm only managing these objects via pulumi. All updates are applied via

pulumi up

. I'm not creating/updating kubernetes objects directly via

kubectl

or through another mechanism. What would be an example of: > but if you have other operators acting on it (or if you’ve made manual changes) it can be useful

if you’re seeing “conflict detected” errors (and using a recent 4.x version of provider) the error should include the field manager it’s conflicting with.

Thank you! I did come across that and played around with disabling SSA and using the

forcePatch

option. Both made the errors go away, but I think the errors were an indication of a problem in our implementation. Turns out, we were needlessly explicitly naming Secret and ConfigMap objects instead of letting Pulumi autoname them. Once we removed the explicit names in the metadata, dependencies between resources were greatly simplified and we no longer saw the errors related to cluster state and Server-Side Apply field conflicts. The lesson here is when possible, let Pulumi autoname objects.