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.

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

Support arbiters with MongoDB Kubernetes Operator so that Replicasets should be deployed in PSA configuration.

Allow configuration of backup settings in MongoDB Custom resource.
This includes management of backed up resources when updating, moving or deleting clusters

1.) What is the limiting factor of the Operator? Is it number of Pods, number of Custom Resources (e.g. MongoDB, MongoDBUser) or something else?

2.) What does the number of "Clusters" refer to? Does it differ for Standalone, ReplicaSet and ShardedCluster?

3.) How many instances of the "Clusters" in 2.) are supported per MongoDB Operator?

Is there any way to add this sort of data to our documentation?

Thanks

Provide a helm chart that deploys MongoDB, MongoDBUser, secrets and all other resources needed.

The goal is to simplify the deployment of a MongoDB instance and everything that comes with it down to a helm one-liner.

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.

Show some of the Kubernetes resources in Ops Manager
1. show namespaces in projects,
2. Show list of resources in cluster view

When cluster is deployed, each mongo server start to generate a logfile "/var/log/mongodb-mms-automation/mongodb.log", we got an outage because it gets the disk full.
It will be useful if we can specify a value to rotate and purge the log.

Ops Manager can utilize S3 storage for the Oplog Store. It should be possible to define and configure an S3 Oplog Store from the Operator.

Should provide sharding feature in community Operator.

In ops-manager.yaml, can we define the number of the initial backup daemons?

Arm64 processors are getting more and more popular. Would be really nice to be able to run MongoDB Kubernetes Operator on a Raspberry Pi cluster.

Otherwise, meanwhile would be nice to get documentation updated on how to produce arm64 images to still make it possible without having full CI infrastructure support.

Labels and annotations added to Kubernetes resources by the MongoDB Enterprise Operator should include a prefix designating that it was added by MongoDB. The lack of a prefix suggests the field and values are private to the user.

For example, the MongoDB statefulset and service selector should use a label prefixed with a MongoDB domain.

https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set

By default, when enabling backups and configuring a Blockstore for an Ops Manager custom object, the specified Blockstore will be set as "Assignment enabled" in the UI.

It would be helpful to expose the enable/disable button for the blockstore through the CRD since disabling it through the UI, results in the parameter being reverted every time the operator consolidates. This is useful for the case when more than a single store is configured and as a user you would like to disable the blockstore to make it unavailable for new backup jobs.

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