Support a permanent "managed external" (no-StatefulSet) deployment mode on top of the VM-migration externalMembers

[yuvalgl]

Summary / use case

We operate a fleet of self-managed MongoDB Enterprise deployments that run on
VMs/bare-metal and are registered in Ops Manager, with process lifecycle handled
by OM automation + our configuration management. We'd like to manage these
deployments declaratively through MCK CRs — users, roles, auth, TLS, backup, and
topology/config — as a permanent steady state, with the operator NOT creating
StatefulSets. This is the inverse of a migration: the mongod processes are meant
to stay off-Kubernetes.

What we found (and really like)

The VM-to-Kubernetes migration epic (#800, with #1042 merged and #1133 open)
already introduces almost everything needed:

• spec.externalMembers + replicaSetNameOverride
• external-aware merge logic (MergeReplicaSet keeps external processes,
  GetNumberOfExcessProcesses ignores them, limitVotingMembers no-ops,
  externalAgentVersion read from OM)
• the kubectl mongodb migrate import tool that generates zero-diff CRs

The gap for our use case

The epic is intentionally migration-shaped (external members are transitional and
pruned; steady state = all-Kubernetes). For permanent external management we'd
need a "managed external" mode where:

• spec.members: 0 is allowed and no StatefulSet/Service is created;
• externalMembers can be added/edited (to manage topology), not just removed;
• no migration completion/pruning is required.
  Today noExternalMembersAdditionOrChanges, atMostOneMigrationChangeAtATime, and
  the always-on StatefulSet build prevent this.

Questions

1. Is a permanent managed-external (zero-StatefulSet) mode something you'd consider
   in scope for MCK, or is it intentionally out of scope (migration-only)?
2. If in scope, would you prefer it layered on externalMembers (a steady-state /
   managed flag) or as a separate API surface?
3. Would you accept community PRs for this on top of the epic branch, and how would
   you want it sequenced relative to the epic merging to master?

We're prepared to contribute (short design doc + incremental, CLA-signed PRs,
starting with ReplicaSet) and to test against real external OM-managed deployments.

cc @nammn @lucian-tosa @filipcirtog

[vinilage]

Hi @yuvalgl!

My name is Vini, and I’m the Product Manager for the MongoDB Community Kubernetes Operator (MCK). Thanks for opening this detailed ticket, and nice to connect with you!

To give you some context on where we're headed: we are currently in the process of redesigning our entire multi-cluster architecture. This is a broader, unified effort across all Enterprise Advanced (EA) components, including Ops Manager and the underlying Agents, aimed at simplifying our overall solutions.

Because of this ongoing redesign, we are intentionally limiting the scope of externalMembers to be a temporary state during the migration process, rather than a permanent deployment mode.

While I truly appreciate your thorough analysis and willingness to contribute code, a permanent managed external mode isn't on our immediate roadmap while this architectural redesign is underway. Once that foundation is in place, we will definitely be in a better position to revisit and reconsider this paradigm.

Thank you again for taking the time to share such a detailed feature request and for being an active part of our community!

[yuvalgl]

Hi @vinilage — thanks for the candid answer, that makes total sense. Keeping
externalMembers as a temporary migration state while the multi-cluster / EA
redesign is in flight is a very reasonable call.

Two quick questions so I can plan around it:

1. Is the redesign's "multi-cluster" scope mainly about multi-Kubernetes-cluster
   topologies, or will it also cover a steady-state way to manage OM-registered
   deployments whose members never run in Kubernetes (permanently external VMs)?
2. Given this is off the near-term roadmap, is there an approach you'd recommend
   for this use case today — e.g. driving the OM Automation Config API directly, or
   something better-supported? Any steer would help us avoid going against where
   MCK is heading.

And near-term: will externalMembers + kubectl mongodb migrate stay available
through the redesign? I'd just like to avoid building on something about to be
removed.

Happy to be an early tester / design partner and to share a detailed use case when
the new architecture firms up. Thanks again!