you can achive it with OpsManager configuration settings mms.fromEmailAddr: "test@test.com" mms.ignoreInitialUiSetup: "true" mms.replyToEmailAddr: "test@test.com" mms.adminEmailAddr: "test@test.com" mms.mail.transport: "smtps" mms.mail.hostname: "mail.example.com" mms.mail.port: "465"

Totally agree. I would describe it as follows: The OpsManager cannot be fully configured via the MongoDBOpsManager resource. There is interaction with the OpsManager API needed for: - Initial settings wizard (mailserver, email addresses etc.) - Backup integration - Creation of a Organization, API keys and IP whitelisting in order to be able to create MongoDB instances for the S3 metadata storage and oplog store - After that Create a Secret and ConfigMap with the data returned from OpsManager Provide a k8s native way to Configure the OpsManager without any interaction towards the OpsManager API Option 1: Provide a way to add this configuration directly in the MongoDBOpsManager resource Option 2: Provide a way to Configure the OpsManager settings via ConfigMap

When deploying a MongoDB resource to a newly installed Operator and OpsManager the user has to Create an Organization, API keys and IP whitelisting in OpsManager Create a Secret and ConfigMap with the data returned from OpsManager Specify this Configmap as "configMapRef" in the MongoDB resource. Please provide a k8s native way to deploy a MongoDB instance without any interaction towards the OpsManager API. The MongoDB Operator should create the Organization, API keys and IP whitelisting in OpsManager and create the secret and configmap. Option 1: Create a CRD "MongoDBOpsManagerOrganization" that has a reference to a secret (containing the private key) and an IP whitelist as parameter. The MongoDB resource then references this MongoDBOpsManagerOrganization Option 2: The MongoDB Operator automatically creates an Organization per Namespace containing MongoDB resources. The user does not need to create any Organization, API keys, IP whitelisting, Secret and ConfigMaps.