Changing a secret's data always results in a replace insted of an update

[johnb8]

Hello!

• Vote on this issue by adding a 👍 reaction
• To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already)

Issue details

When the data or stringData of a Secret is modified, Pulumi wants to do a replace instead of a update.

Steps to reproduce

Deploy this Pulumi script

import * as k8s from "@pulumi/kubernetes";

const kubeProvider = new k8s.Provider("main", {
  context: "minikube",
  namespace: "secret-test",
});

const namespace = new k8s.core.v1.Namespace(
  "main",
  {
    metadata: {
      name: "secret-test",
    },
  },
  { provider: kubeProvider }
);

const secret = new k8s.core.v1.Secret(
  "secret-env",
  {
    metadata: {
      name: "secret-env",
      namespace: "secret-test",
    },
    stringData: {
      test: "super secret",
    },
  },

  { provider: kubeProvider }
);

then change the test secret value and deploy again. Pulumi will replace the secret. The same happens when using data instead of stringData too.

I'm using Pulumi version 3.15.0 and @pulumi/kubernetes 3.8.1.

Expected: Pulumi should do an update on the Secret
Actual: Pulumi replaces the Secret

[mikhailshilkov]

Thank you for reporting this!

This is currently the expected behavior, see #1568 for description. We may consider an improvement here, so I'll leave the issue open for now.

[lblackstone]

I opened #1775 to track a planned improvement here.

[johnb8]

Sorry I missed that issue. Using replaceOnChanges to override the default behaviour would be a nice improvement.

I probably should have included in my original issue that when that Secret is updated and used by a Deployment the Deployment is replaced as well, resulting in downtime. I know now that I can let Pulumi auto-name the secret to avoid this (as mentioned in #1567, thanks for linking that!), though it would be nice to have a static name for the Secret.

But since Pulumi knows that the Deployment needs to be changed when the Secret changes if the Secret behaviour was changed to update wouldn't the Deployment only be updated too and restarted in the process avoiding concern 1 mentioned here #1567 (comment)?

I guess once replaceOnChanges allows overriding the default those concerns will be irrelevant anyway, since the user can decide what they want

[lblackstone]

But since Pulumi knows that the Deployment needs to be changed when the Secret changes if the Secret behaviour was changed to update wouldn't the Deployment only be updated too and restarted in the process avoiding concern 1 mentioned here #1567 (comment)?

The Deployment should be updated (not replaced) using a rollout, so it generally shouldn't cause downtime.

[johnb8]

Right, I think it was doing a replace because I was using apply in my other project, instead of just referencing the secret and keys directly. Thanks for the clarification!

[protometa]

I'm having this issue changing a named secret referenced by imagePullSecrets which triggers full replacement of the deployments. Changing the secret to auto-name will merely trigger updates of the deployments, but that's still undesired behavior to my understanding since imagePullSecrets only need be looked up on the next redeployment at the earliest. The auto-named reference is causing an unnecessary update to the spec and redeployment.

[blampe]

@protometa @gunzy83 @johnb8 FYI support for mutable secrets was added in v4.18 -- see the release notes. Note this might become the default behavior in a future major release.