boundless-carpenter-84747
10/29/2024, 11:27 PMpulumi 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 updateI 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
.boundless-carpenter-84747
10/29/2024, 11:30 PMpulumi up
(without --refresh
), the stack is totally broken after the update (no Deployments exist, and further attempts to interact with pulumi on the stack result in unable to get cluster state
errors.) This is using EKS if it matters.
If I use pulumi up --refresh
this fixes the errors and all the updates are applied as expected. I'd like to understand when I need to use --refrsh
and when I shouldn't.hallowed-photographer-31251
10/30/2024, 12:03 AMrefresh
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.boundless-carpenter-84747
10/30/2024, 2:23 AMrefresh
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 usefulhallowed-photographer-31251
10/30/2024, 4:45 PMboundless-carpenter-84747
11/01/2024, 4:20 PMforcePatch
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.