This is a feature request to have custom environment variables, configured in the MongoDB Operator's Deployment manifest, push down or propagate to all resources created by the Operator.

For example, it may be desired to add environment variables with context. A more specific example could include setting a TZ timezone environment variable that is automatically added to all pod containers created by the Operator.

MongoDB Operator can only deploy and manage MongoDB in a single Kubernetes cluster. However, for DR and global apps, it is important to deploy a single DataBase across multiple Kubernetes clusters to allow for DR or globally distributed apps.

Should provide sharding feature in community Operator.

Currently, the operator does not enable backup function for AppDB, but it does enable monitoring. For everything else (non-AppDB) the operator does enable the Backup and Monitoring functions, even if backup is not configured

At the moment none of these functions are configurable with the Operator. The only method to disable the Backup or Monitoring function is through the Ops Manager UI.

Requesting the ability to manage the functions through the operator.

I believe kubernetes taints and tolerations are not supported by the operator, yet I find it a much needed capability.

Currently, if you want to assign a snapshot store to a certain project, it is required to access the Admin view and configure the "Assignment Labels" property under Backup > Snapshot Storage with the name of the corresponding project.

AFAIK, it is not possible to assign this configuration in the Ops Manager's YAML. E.g.:

s3Stores:

- mongodbResourceRef:

    name: s3-metadata-db

  mongodbUserRef:

    name: s3-meta-store-user

  name: s3store1

  pathStyleAccessEnabled: false

  s3BucketEndpoint: endpoint1.corp

  s3BucketName: backup1-bucket

  s3SecretRef:

    name: s3-credentials

- mongodbResourceRef:

    name: s3-metadata-db

  mongodbUserRef:

    name: s3-meta-store-user

  name: s3store2

  pathStyleAccessEnabled: false

  s3BucketEndpoint: backup2.corp

  s3BucketName: backup2-bucket

  s3SecretRef:

    name: second-credentials

During maintenance work EKS admins may need to evict nodes. This should not cause outage for MongoDB cluster/replicaset running on these nodes. we can create manually PDB for STS, but it would be nice to have an option to do it as part of MongoDB Kubernetes Operator.

Operator automatically provision an Ops Manager programmatic API key, The current instructions require human intervention to create an AP

The default port is 8080 or 8443 (for https) and cannot be changed

Please, build a course like you already have but now for Kubernetes Operator. I had serious troubles implementing it.

For the purpose of regularly performing backups of the AppDB using mongodump --oplog.

currently for release 1.9.0, the helm chart has no way to explicitly use a specific version of the following images:
- mongodb-enterprise-ops-manager
- mongodb-enterprise-appdb

This is not ideal and hard to scale in the enterprise. Request the ability to pin versions to all images from values file.

Currently it is not possible to delete a project via kubectl command.

As the Kubernetes Operator allows one to create a project (configmap) and deploy a replica set, we would expect it to also allow the deletion of a project so that we can fully automate the solution.

Currently Ops Manager CRD deployment requires configuration using GUI which is a manual step. An option completely define all OPS Manager settings / Org in declarative manner via yaml will be great in building completely automated CI/CD Pipelines

Should be able to pin tags for images like mongodb-enterprise-appdb in https://github.com/mongodb/mongodb-enterprise-kubernetes/blob/master/helm_chart/values.yaml

Currently, we are forced to use the latest tag, which has caused issues and broke disaster recovery for our project.

If we would have been able to use an older tag of the image, we could have recovered fast. since we were forced to use the latest tag, it took several days to recover. This does not seem acceptable for an enterprise software.