This message was deleted.

wow, you’re right. it happens here too. looks like Pulumi uses

kubectl apply

to apply the secret, which makes . The “correct” way to do it seems like it would be to use

kubectl create

the first time, and then

kubectl replace

on subsequent updates, which does not retain a

last-applied-configuration

annotation (ref https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/) would you like to make a github issue? 😄

@broad-helmet-79436 https://github.com/pulumi/pulumi-kubernetes/issues/965

awesome work 👍

I added the pulumi & k8s provider versions to the ticket.

hopefully someone who knows how this works will pick up on it soon. I have a feeling it’s going to have to be fixed in the terraform provider though…

@broad-helmet-79436 don’t think so as the Pulumi k8s provider is one that doesn’t depend on the TF provider. 😉

oh, you’re right!

Sure, interested to hear more

I would like to find out about the difference in the two scenarios: 1. I create a secret via CLI:

kubectl create secret …

and with

kubectl get secret ...

I get a secret without annotation. 2. I create a secret via Pulumi. With

kubectl get secret

I get a secret with the annotation. So is Pulumi doing something different from the CLI?

Generally

kubectl

adds the same annotation, but it might not for Secrets; I’d have to check. Pulumi’s k8s provider adds that annotation to help with client-side diffing.

@gorgeous-egg-16927 so is the GH issue I filed a bug then which will be fixed? It’s a small thing in the end, given that the secret data is only base64 encoded.

I’m chatting with my colleague about it now. It might make more sense for us to always replace Secret resources on update, and get rid of the annotation.