No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

k8s_simple-change-detection-failure.ts

Changing the `image` of a Kubernetes Deployment is *not* displayed as a change with `pulumi up --refresh`.  I changed it directly with `kubectl edit`.

The details view of `pulumi up` shows that the `image` will be refreshed in the stack, though.

What do I do wrong?

(The code is from `pulumi new kubernetes-typescript` with fixed `image` &amp; `minikube` provider.)

Simple test: `kubectl edit deploy nginx-...` &amp; change to `image: nginx:1.16.1-alpine`

package.json

<@UMBT6JBPT> are you able to assist with this?

Sure, I can take a look at this for you Dominik.  Looks like you're trying to POC out the kubernetes functionality?

No, just created a MWE to test if it occurs there, as well. Do you get the same result?

I stumbled upon this behaviour sometimes. Last while deploying `kube-prometheus` which has  many K8s resources.

I’m seeing the change in the *details*  of the `refresh` stage (either `pulumi refresh` or `pulumi up --refresh`).

But I don’t see that `pulumi up` doesn’t want to change the image back to what’s defined in the code, i.e. `nginx:1.6.1`.

<@UMBT6JBPT> I’ve found that this bug is already in an issue: <https://github.com/pulumi/pulumi-kubernetes/issues/694>
&gt; <@U84HBHXS8> indicated that this is expected behavior with legacy diff because the kubectl scale command apparently doesn’t set the `<http://kubectl.kubernetes.io/last-applied-configuration|kubectl.kubernetes.io/last-applied-configuration>` annotation.

The solution is to use the new Kubernetes provider option `enableDryRun: true` (hint: there may be stability issues with it as mentioned in the Github issue).

Okay, I've made the engineering team aware.  Currently is there anything about using enableDryRun that will block you from your desired workflow for now?

<@UMBT6JBPT> No, using `enableDryRun` seems fine for now. Didn’t use it in bigger projects, yet. Currently working on other things.

Sorry for the late answer. Just realized that I don’t get any notification from threads. Best is you always @mention me. Then it’s sure I’ll receive a notification.