This message was deleted.

The set of properties we treat at force replacement is here: https://github.com/pulumi/pulumi-kubernetes/blob/f1a6f90015ee7a2a316603308960c2a33b4db44e/pkg/provider/diff.go#L158 I believe the intention is that these match cases where Kubernetes does not support in place updates of the properties. Do any of those look wrong to you? Or are you not changing any of those?

It does not seem I am changing any of those:

+-kubernetes:apps/v1:StatefulSet: (replace)
        [id=lightning/btcd-ltp0qgqg]
        [urn=urn:pulumi:main::lightning::kubernetes:apps/v1:StatefulSet::btcd]
        [provider=urn:pulumi:main::lightning::pulumi:providers:kubernetes::infrastructure::4ae1f6ee-c651-431e-ab0d-8123dd853a0e]
      ~ spec: {
          ~ template            : {
              ~ spec    : {
                  ~ containers: [
                      ~ [0]: {
                              ~ args           : [
                                  + [2]: "-rpcuser=lightning"
                                  + [3]: "-rpcpassword=lightning"
                                ]
                            }
                    ]
                }
            }
        }

You are, containerForceNewProperties includes args

It seems that should only apply for a

Pod

Isn’t a StatefulSet a Pod?

Well I certainly don't understand how this code works, maybe it is indeed causing

StatefulSet

replacement if

args

change. But I would expect that should not cause a replacement of the

StatefulSet

itself. The spec changes, and should in turn trigger a rolling deploy, replacing the individual pods one at a time, but not entirely replacing the stateful set. Doing that loses all of the stateful data and defies the whole point.

Is it actually replacing, or telling you it will?

It is actually replacing, and resulting in new PVC's.

@millions-judge-24978 Can you file an issue? That may be an oversight with statefulsets since Pulumi’s typical workflow is to create a new instance of the resource and then delete the old one. I certainly wouldn’t expect it to use different PVCs.

Sure, what's odd is I swear this wasn't happening before, or I would have encountered it long ago, but I tried older versions to no avail. There's no chance this is related to auto-naming funkiness and not just due to an oversight on the diff code right?

It could possibly be related to auto-naming, but I’d need to take a closer look to be sure. In general, it’s easier to just close out issues if it turns out to be nothing, so don’t hesitate to file if you see something weird.

👍