It is not possible to pass unique labels and selectors on arbiter and mongo members.

[prachiwaghulkar]

We can not pass unique labels and selectors for arbiter and mongo members sts. Currently, whatever labels and selectors we are passing through mongodbCommunity yaml is being picked up by both mongo members and mongo arbiter.

Expected behavior:
We should be able to pass unique/different labels and selector to arbiters and mongo members

Expecting something similar to this:
specs.template.metadata.members.labels and specs.template.metadata.arbiters.labels and same goes for selector configuration as well.

[Julien-Ben]

Hi @prachiwaghulkar,
Thank you for reporting this issue

This is not something we plan to support soon, but we would consider doing so if more users request this feature.
In the meantime, we welcome any contributions from the community

[Alveel]

Hi @Julien-Ben, I'd like to add our vote for adding this feature.

We use Kasten K10 for backups with label selectors to include/exclude items. Unfortunately Kasten does not have the ability to filter names with wildcards. Thus this would mean that we would have to manually exclude every single arbiter statefulset resource from the backup schedule.

If we were to have the ability to add custom labels we would not have this issue.

A more simple solution for now might be to always add a specific label to the arbiter statefulset/pods to make it distinguishable from the primary/replicas?

[Julien-Ben]

Hi @Alveel
Thank you for your input

We will consider implementing this feature

Note that you can also raise feature requests on https://feedback.mongodb.com/forums/924355-ops-tools
We recently created a new category for the Community Operator there.

[Alveel]

Hi @Julien-Ben, thanks for the feedback. I have created the feature request as per your link here.

[SanYattsu]

@Julien-Ben, is it possible to set pvc for arbiter to 0 without this feature implemented? How can I modify volumeClaimTemplates only for members?

[realtimetodie]

Are there any updates on this? There is currently no way to tell whether a pod is actually an arbiter or a primary.

The only way is to run mongo CLI to get the current configuration status:

db.runCommand(isMaster).primary