version.BuildInfo{Version:"v3.2.0", GitCommit:"e11b7ce3b12db2941e90399e874513fbd24bcb71", GitTreeState:"clean", GoVersion:"go1.13.10"}
Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.6", GitCommit:"dff82dc0de47299ab66c83c626e08b245ab19037", GitTreeState:"clean", BuildDate:"2020-07-15T16:58:53Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.7", GitCommit:"5737fe2e0b8e92698351a853b0d07f9c39b96736", GitTreeState:"clean", BuildDate:"2020-06-24T19:54:11Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"}
          
With Helm chart 7.14.8, problem does not exist because other replica parameters can be set and initConfigMap.name value will only be applied on mongodb-primary.
replicaSet.enabled

replicaSet.replicas.secondary

replicaSet.replicas.arbiter
Is there a different solution for init scripts with Helm Chart version => 8.0.0?
if [[ "$HOSTNAME" = *"-0" ]]; then
  mongo admin --authenticationDatabase admin -u root -p $MONGODB_ROOT_PASSWORD <<EOF
  use ajila-1234
  db.createUser(
      user: "ajila-1234",
      pwd: "$MONGO_AJILA_1234_USER_PASSWORD",
      roles: [
        { role: "readWrite", db: "ajila-1234" }
  use ajila-12345
  db.createUser(
      user: "ajila-12345",
      pwd: "$MONGO_AJILA_12345_USER_PASSWORD",
      roles: [
        { role: "readWrite", db: "ajila-12345" }
          
Hi @juan131
My workaround is not really working after restarting the master pod.

The shell init script is executed again and then it fails.
Have you been able to reproduce the error on your own infrastructure?
          
Yes @ajila-fmeyer
It's related to the major refactorization we did on the version 8.0.0.
Previously there were 2 statefulsets: one for primary nodes, and another one for secondary nodes; and the initscripts were included exclusively in the primary statefulset. Now we have a unique statefulset. The secondary nodes should ignore the initscripts but for some reason they're not doing so. I'm trying to figure out why
          
Could you try including in your script sth like?
if [[ "$MONGODB_REPLICA_SET_MODE" = "secondary" ]]; then
   echo "skipping..."
   (the rest of your script)
          
@juan131
Initial setup looks fine 👍

When I initiate a redeploy, I get the following error message on the master pod.
mongodb 07:56:27.26 
mongodb 07:56:27.26 Welcome to the Bitnami mongodb container
mongodb 07:56:27.26 Subscribe to project updates by watching https://github.com/bitnami/bitnami-docker-mongodb
mongodb 07:56:27.26 Submit issues and feature requests at https://github.com/bitnami/bitnami-docker-mongodb/issues
mongodb 07:56:27.27 
mongodb 07:56:27.27 INFO  ==> ** Starting MongoDB setup **
mongodb 07:56:27.28 INFO  ==> Validating settings in MONGODB_* env vars...
mongodb 07:56:27.30 INFO  ==> Initializing MongoDB...
mongodb 07:56:27.32 INFO  ==> Enabling authentication...
mongodb 07:56:27.33 INFO  ==> Deploying MongoDB with persisted data...
mongodb 07:56:27.33 INFO  ==> Writing keyfile for replica set authentication...
mongodb 07:56:27.36 INFO  ==> Loading custom scripts...
mongodb 07:56:27.36 INFO  ==> Loading user's custom files from /docker-entrypoint-initdb.d ...
MongoDB shell version v4.2.8
connecting to: mongodb://127.0.0.1:27017/admin?authSource=admin&compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("21e452ae-3e15-4f00-9f3f-be0ae027160f") }
MongoDB server version: 4.2.8
switched to db ajila-cloud-auditing
2020-08-20T07:56:28.671+0000 E  QUERY    [js] uncaught exception: Error: couldn't add user: not master :
_getErrorWithCode@src/mongo/shell/utils.js:25:13
DB.prototype.createUser@src/mongo/shell/db.js:1370:11
@(shell):1:1
switched to db ajila-cloud-storage
2020-08-20T07:56:28.673+0000 E  QUERY    [js] uncaught exception: Error: couldn't add user: not master :
_getErrorWithCode@src/mongo/shell/utils.js:25:13
DB.prototype.createUser@src/mongo/shell/db.js:1370:11
@(shell):1:1
mongodb 07:56:28.68 INFO  ==> Stopping MongoDB...
          
Hello @juan131
This workaround with creating a new file in folder /bitnami/mongodb and checking that works 👍

Is it planned from your end (Bitnami) to double check/further investigate for a better/proper solution?