StatefulSet not updated when adding environment variable to CR

[bitfisher]

Report

I added a environment variable to an exiting PerconaServerMongoDB but Sts never get's updated.
Manually added environment variable to Sts and forced a reconcile removes environment variable from sts altough it's present in CR.

More about the problem

Environment variables passed to Sts

Steps to reproduce

1. Deploy PerconaServerMongoDB
2. Edit CR, add env to replsets
3. Watch for Sts updated - never happens

Versions

1. Kubernetes: 1.34.6
2. Operator: 1.22.0
3. Database: 8.0.20

Anything else?

No response

[egegunes]

@bitfisher could you please tell me the value of spec.crVersion in PerconaServerMongoDB object?

[bitfisher]

crVersion: 1.21.1

i didn't set this explicitly cause i assumed this is updated by operator implicitly.

NAME               	NAMESPACE   	REVISION	UPDATED                                	STATUS  	CHART                     	APP VERSION
psmdb-operator     	psmdb-system	7       	2026-03-05 14:28:32.545729221 +0100 CET	deployed	psmdb-operator-1.22.0     	1.22.0     
psmdb-operator-crds	psmdb-system	4       	2026-03-05 14:46:57.575164123 +0100 CET	deployed	psmdb-operator-crds-1.22.0	1.22.0     

using following update-/upgrade-options:

  updateStrategy: SmartUpdate
  upgradeOptions:
    apply: disabled
    setFCV: true

[gkech]

Just checked the issue using the main images, with cr version 1.23, applying the following on replset 0:

    env:
    - name: SOME_NAME_1
      value: VALUE
    - name: SOME_NAME_2
      value: VALUE1

And both the sts and the respective replset pods were updated.

I'll also check 1.22 images with 1.22 cr version.

[gkech]

Note that if you are using cr version older than 1.22.0, this is expected to not work because it was released with 1.22.0 as noted here: https://docs.percona.com/percona-operator-for-mongodb/env-vars-custom.html

[gkech]

Just checked the issue using the main images, with cr version 1.23, applying the following on replset 0:

    env:
    - name: SOME_NAME_1
      value: VALUE
    - name: SOME_NAME_2
      value: VALUE1

And both the sts and the respective replset pods were updated.

I'll also check 1.22 images with 1.22 cr version.

1.22 images with 1.22 cr version seem to work fine as well.

@bitfisher can you please retry with cr version 1.22 and let us know if it works for you?

[bitfisher]

Note that if you are using cr version older than 1.22.0, this is expected to not work because it was released with 1.22.0 as noted here: https://docs.percona.com/percona-operator-for-mongodb/env-vars-custom.html

i know, but i assumed crVersion is updated automatically as i never specified it explicitly.

docs are not very clear about this ... or i misunderstood something.

[gkech]

Note that if you are using cr version older than 1.22.0, this is expected to not work because it was released with 1.22.0 as noted here: https://docs.percona.com/percona-operator-for-mongodb/env-vars-custom.html

i know, but i assumed crVersion is updated automatically as i never specified it explicitly.

docs are not very clear about this ... or i misunderstood something.

If you completely omit the cr version specification on the cr file, the operator autoresolves the latest cr version based on your image, so for example if you are using 1.22 operator, cr version will be automatically set to 1.22. You can follow the logic from here: https://github.com/percona/percona-server-mongodb-operator/blob/main/pkg/version/version.go

So for (notice that crVersion is commented out)

apiVersion: psmdb.percona.com/v1
kind: PerconaServerMongoDB
metadata:
  name: my-cluster-name
  finalizers:
    - percona.com/delete-psmdb-pods-in-order
spec:
#  crVersion: 1.22.0
  image: perconalab/percona-server-mongodb-operator:main-mongod8.0
  imagePullPolicy: Always
[....]

You will get something like this when using 1.22 images:

Name:         my-cluster-name
Namespace:    nynamespace
Labels:       <none>
Annotations:  <none>
API Version:  psmdb.percona.com/v1
Kind:         PerconaServerMongoDB
Metadata:
  Creation Timestamp:  2026-04-28T09:02:43Z
  Finalizers:
    percona.com/delete-psmdb-pods-in-order
  Generation:        2
  Resource Version:  1777366971749919023
  UID:               e05e837a-944b-4ba9-acde-32dfd22afe18
Spec:
  Backup:
    Enabled:  true
    Image:    perconalab/percona-server-mongodb-operator:main-backup
    Pitr:
      Compression Level:        6
      Compression Type:         gzip
      Enabled:                  false
      Oplog Only:               false
    Starting Deadline Seconds:  120
  Cr Version:                   1.22.0
  Image:                        perconalab/percona-server-mongodb-operator:main-mongod8.0
  Image Pull Policy:            Always

[bitfisher]

that's exactly what i did - omitting crVersion.

what's the behaviour on operator/cr updates then?

[gkech]

@bitfisher wondering if you are using helm charts for your deployment

[bitfisher]

yes. using helm for operator/crd as well as my own chart for PerconaServerMongoDB (used as dependency in other charts).

[gkech]

yes. using helm for operator/crd as well as my own chart for PerconaServerMongoDB (used as dependency in other charts).

Looking at charts/psmdb-db/templates/cluster.yaml, the replset loop handles many fields like resources, affinity, tolerations, sidecars, containerSecurityContext, etc. but there is no handling for $replset.env anywhere.

https://github.com/percona/percona-helm-charts/blob/main/charts/psmdb-db/templates/cluster.yaml#L148

I'll prepare a ticket to fix the helm chart.

[bitfisher]

so, if i understand you correctly, it's intended to update CR's crVersion manually?