Scenario:

Assumptions:
autoscaling = true
current instanceSize = M40
minInstanceSize = M30
maxInstanceSize = M70

If we want to increase the minInstanceSize from M40 to M50 operator will return an error because our current instance size is less than M50, so we need to go to UI and increase the current instance size to M50(at least), and then apply the change to Kubernetes object (atlasdeployment).

We expect that if the current instanceSize is not in the range, the operator automatically increases the instanceSize to minInstanceSize to remove the extra step.

We expect the same logic for increasing/decreasing - minInstance/maxInstance and disk for an autoscaled cluster.

atlas-reconciliation-policy=skip flag provide ability do not sync k8s object status with atlas. But in case when we need to make reference on objects in Atlas and do not create or modify resources this flag do nothing. In this case i would be good if or operator sync object from API to k8s resources or at least provide opportunity to set id or made reference to specific resource.
Aka:

• Follow the pattern of reading data from the objects even if not doing reconciliation for them. This is the norm for controllers
• Support referencing api paths rather than just object references for the AtlasDeployments

Currently, whenever an index build is kicked off on a replica set, it tends to trigger a "host is down" alert. Although this is benign and a false positive alert the on-call DBA has to wake up in the middle of a night when this alert pages us to make sure the host is NOT DOWN. When the monitoring agent tries to ping a node (where index build is running) and fails to communicate with it, it tends to think that the host is down and triggers this alert, although the host is up and running. When an index build is kicked off, it is capture in the mongodb.log. If monitoring agent can check the mongodb.log for an index build or somehow be notified that an index build is running on a node, so NOT to trigger a host is down, that would really help with all the false positive alerts that are being generated.

The Ops Manager authentification process through SAML requires that the user's groups are specified in a dedicated SAML attribute sent by the IDP, so the user can connect to Ops Manager.

For this need, our IDP can only provide a field that contains free text. This field can contain many information, and can include special characters. We can add the Ops Manager groups in this field, among the existing text information.

However we need Ops Manager to parse this free field and get the groups information, which is not possible for now.

That's why we would like the implementation of regexp, or another solution, in OpsManager, so it can find the user's groups information in a "SAML Group Member Attribute" field containing many other information.

Issue:
Current requirement to enable 'auto upgrades' to test and take advantage of Minor version updates (Example: 6.x.x >> 6.y.x). As a larger company with a 2-4 week release cycle in our products, we have seen need to start testing a Minor version upgrade to the current Major GA Release (Recent example below).

Scenario where this could be a problem in summary (See detailed real world story further down):
- Customer sees a new feature they wish to try.
- Customer is pegged to last major version upgrade (currently 6.0.x) to allow for pegging the version in production
- Customer cannot allow for 'auto upgrades' in production due to internal Release Management requirements, and must wait the full year cycle for features added in later minor versions of the current major release.

The Ask: We respectfully request a resolution to a state where we can choose to peg any of our clusters to a specific minor version (i.e. 6.1.x, or 6.2.x...) and allow only auto upgrades in the patch/bug release numbers rolled out by Atlas. Thank you for your time and response to this critical upgrade in scheduling & control over Minor version upgrades.

More detailed summary of need for control over Minor Release Update Cycles/Scheduling:
As we have our own release management requirements, any change to a Production environment must go through UAT and Performance testing and approval before the release. Currently, with requirement of enabling 'auto upgrades' to move up to available Minor Release, we are hamstrung until late in the Major release cycle to begin testing and releasing a minor version in lower environments to then implement in Production. this is due to our internal Release Management requirement to peg the MongoDB version and driver in Production to a fully tested release, and to have lower environments testing and validating on same IaaS release version as production. And pegging a version is only allowed at the Major version going to GA. We wish to ask that Minor versions be left to live for 12-15 months to allow for pegging a minor version upgrade during the year. This would allow our teams to implement a Minor version upgrade early... and peg to that version pending the annual GA release to come.

Below I highlight the real world example that caught our team in a catch-22 with v5.0 not meeting requirements of our application in sharded configuration, requiring us to enable 'auto upgrades' to get to 5.1.x or later.

Resulting Request:
We would like the ability to peg our clusters to specific minor releases. Example: to 5.3.x where patch releases are acceptable, but minor version updates to 5.4.x are not allowed until we have tested and approve within same our own CICD pipeline and process.
Allowing for 'auto upgrades' in our clusters based on Atlas rollout schedules poses unwarranted risk to the production assets of the End Users
The ability to be alerted of available minor updates with option to choose when to begin our own test/release and schedule same is requested.

Recent situation/scenario:
With requirement for 'auto updates' we were in a catch-22 with 5.0.x And 5.3.x, where we needed the features of graph lookup with sharded configuration in production.
- We are rapidly reaching critical resource issues in Production with a Primary/Replica configuration.
- We must proceed with upgrade to Sharded configuration to 1) allow for horizontal scaling to relieve pressure on Primary nodes for Read Preference Primary for mission critical operations requiring high idempotency, and that do not allow for eventual consistency within the SLAs and 2) relieve pressure on Oplogs due to high throughput and rapid data changes during normal operations. We have operations that lead to a requirement on a primary/replica set to be now 1.2TB to prevent OpLog window from dropping below 12hrs. - With horizontal scaling, we can spread the load on read primary across multiple nodes, which will alleviate the need for such a large Oplog Size, leading to better management and availability of storage.
Without the 5.3.2 upgrade and change in our current primary/replica >> sharded configuration. We could not proceed with the much needed upgrades without accepting release management risks associated with enabling 'auto upgrades'. Although the recent scenario is resolved as 6.0 is now GA, if this were earlier in the GA release cycle, we would either 1) be blocked from the above critical upgrades, or 2) Forced to accept the risks of an 'auto upgrade' being implemented in Production ahead of our NonProd clusters. Going against best practices for Release Management.

Hey!

We are using fluent-bit to push MongoDB logs to Elasticsearch. When there are already logs in the elastic index, where attr.error is an object, then it does not accept log lines in which this field is a string:

“error”:{“type”:“mapperparsingexception”,“reason”:“object mapping for [attr.error] tried to parse field [error] as object, but found a concrete value”}

There is log with string attr.error:

{“t”:{"$date":“2022-05-13T15:16:31.203+00:00”},“s”:“I”, “c”:“CONNPOOL”, “id”:22572, “ctx”:“MirrorMaestro”,“msg”:“Dropping all pooled connections”,“attr”:{“hostAndPort”:“mongodb-1.mongodb-headless.mongodb.svc.cluster.local:27017”,“error”:“ShutdownInProgress: Pool for mongodb-1.mongodb-headless.mongodb.svc.cluster.local:27017 has expired.”}}

There is log with object attr.error:

{“t”:{"$date":“2022-05-13T15:20:56.857+00:00”},“s”:“I”, “c”:“REPL_HB”, “id”:23974, “ctx”:“ReplCoord-680”,“msg”:“Heartbeat failed after max retries”,“attr”:{“target”:“alerta-mongodb-arbiter-0.alerta-mongodb-arbiter-headless.monitoring. svc.cluster.local:27017”,“maxHeartbeatRetries”:2,“error”:{“code”:93,“codeName”:“InvalidReplicaSetConfig”,“errmsg”:“replica set IDs do not match, ours: 61ea35f29cfd494fef169571; remote node’s: 61eef8589d065c56e61d6e52”}}}
bitnami/mongodb:4.4.12-debian-10-r18 docker image is used

Could you direct CONNPOOL error message to attr.error.errmsg instead of attr.error (the same as REPL_HB error message)?

I understand that I can make a filter in fluent-bit, but the root cause will remain a problem for other users using structured logging as well.
I think many people have this problem, but not everyone could notice the absence of some logs.