docs: add ADR for autonomous platform clusters by n3rdc4ptn · Pull Request #93 · openmcp-project/docs

n3rdc4ptn · 2026-05-07T09:47:32Z

What this PR does / why we need it:

Adds an ADR proposing autonomous platform clusters as the target architecture for OpenControlPlane bootstrapping and lifecycle management.

Which issue(s) this PR fixes:
openmcp-project/backlog#555

Release note:

Add ADR for autonomous platform clusters based on RGDs and OCM distributions

Signed-off-by: Moritz Marby <moritz.marby@sap.com>

Signed-off-by: Valentin Gerlach <valentin.gerlach@sap.com>

MichaelSp · 2026-06-24T12:33:17Z

That sounds like a big win! Reducing the upfront requirements is an important step.

For my understanding, the requirements for an initial Platform cluster are:

Gardener Cluster with
- 'kro' installed
- 'ocm' installed
Access to a cluster provider (gardener seed | kind)

Is that correct?
Any chance to also include kro+ocm into the self-inflating setup?

Update the autonomous clusters ADR to use ocmRepoName instead of ocmComponentName, introduce an explicit OCM Repository resource, and switch component definitions from externalRef to template. Clarify how distributions instantiate per-component RGDs rather than repeating install logic. Also fix typos and normalize dashes. Signed-off-by: Moritz Marby <moritz.marby@sap.com>

n3rdc4ptn · 2026-07-16T09:15:28Z

That sounds like a big win! Reducing the upfront requirements is an important step.

For my understanding, the requirements for an initial Platform cluster are:

Gardener Cluster with

'kro' installed

'ocm' installed

Access to a cluster provider (gardener seed | kind)

Is that correct? Any chance to also include kro+ocm into the self-inflating setup?

Yes, thats exactly how this is intended.

cluster-provider is installed through self inflating setup. So just ocm and kro are needed. (Maybe flux.)

As we need kro + ocm for the self inflating setup, it would be a chicken egg problem. I think the first iteration needs to just have this as a manual installation, but we could iterate on it and improve in future.

Signed-off-by: Moritz Marby <moritz.marby@sap.com>

maximiliantech

I really like this ADR! The structure and the overall explanation are strong 💪
I have some comments on topics that should get addressed before merging. Could you have a look please @n3rdc4ptn? ⬇️

maximiliantech · 2026-07-31T13:41:53Z

+
+## Current state
+
+The current setup uses the `openmcp-bootstrapper` CLI to bootstrap a production installation. Before running it, an operator must manually provision a target Kubernetes cluster, set up a non-empty Git repository, and ensure access to the OCI registry. The bootstrapper then pulls component versions and manifest templates from the OCI registry, generates and writes rendered manifests into the Git repository, and deploys FluxCD to the cluster pointing at that repository. From that point on, FluxCD continuously reconciles the cluster state with what is in Git.


Suggested change

The current setup uses the `openmcp-bootstrapper` CLI to bootstrap a production installation. Before running it, an operator must manually provision a target Kubernetes cluster, set up a non-empty Git repository, and ensure access to the OCI registry. The bootstrapper then pulls component versions and manifest templates from the OCI registry, generates and writes rendered manifests into the Git repository, and deploys FluxCD to the cluster pointing at that repository. From that point on, FluxCD continuously reconciles the cluster state with what is in Git.

The current setup uses the `openmcp-bootstrapper` CLI to bootstrap a production installation. Before running it, a platform owner must manually provision a target Kubernetes cluster, set up a non-empty Git repository, and ensure access to the OCI registry. The bootstrapper then pulls component versions and manifest templates from the OCI registry, generates and writes rendered manifests into the Git repository, and deploys FluxCD to the cluster pointing at that repository. From that point on, FluxCD continuously reconciles the cluster state with what is in Git.

maximiliantech · 2026-07-31T13:42:37Z

+
+This means the Git repository is a required external dependency that must be maintained alongside the cluster. The manifests written into it are generated and templated (similar to Helm output), making them difficult to read, understand, or modify by hand. Any configuration change requires re-running the bootstrapper or editing large generated YAML files directly.
+
+Verifying the setup is also a manual process: an operator must check that FluxCD's `GitRepository` and `Kustomization` resources are in a Ready state, confirm that core components are running in the `openmcp-system` namespace, and create a test `ManagedControlPlaneV2` resource to validate end-to-end functionality.


Suggested change

Verifying the setup is also a manual process: an operator must check that FluxCD's `GitRepository` and `Kustomization` resources are in a Ready state, confirm that core components are running in the `openmcp-system` namespace, and create a test `ManagedControlPlaneV2` resource to validate end-to-end functionality.

Verifying the setup is also a manual process: an platform owner must check that FluxCD's `GitRepository` and `Kustomization` resources are in a Ready state, confirm that core components are running in the `openmcp-system` namespace, and create a test `ManagedControlPlaneV2` resource to validate end-to-end functionality.

maximiliantech · 2026-07-31T13:43:05Z

+
+This means the Git repository is a required external dependency that must be maintained alongside the cluster. The manifests written into it are generated and templated (similar to Helm output), making them difficult to read, understand, or modify by hand. Any configuration change requires re-running the bootstrapper or editing large generated YAML files directly.
+
+Verifying the setup is also a manual process: an operator must check that FluxCD's `GitRepository` and `Kustomization` resources are in a Ready state, confirm that core components are running in the `openmcp-system` namespace, and create a test `ManagedControlPlaneV2` resource to validate end-to-end functionality.


Suggested change

Verifying the setup is also a manual process: an operator must check that FluxCD's `GitRepository` and `Kustomization` resources are in a Ready state, confirm that core components are running in the `openmcp-system` namespace, and create a test `ManagedControlPlaneV2` resource to validate end-to-end functionality.

Verifying the setup is also a manual process: an operator must check that FluxCD's `GitRepository` and `Kustomization` resources are in a Ready state, confirm that core components are running in the `openmcp-system` namespace, and create a test `ControlPlane` resource to validate end-to-end functionality.

maximiliantech · 2026-07-31T13:46:37Z

+
+Operating the platform across multiple landscapes has shown that the Git repository introduces meaningful overhead. Because manifests are generated from a single large configuration file, they are not easy to inspect or adjust by hand, and any change requires going back through the bootstrapper. This adds friction during initial setup, local development, and for smaller teams who want to operate a landscape without the need for complex configurations.
+
+Lifecycle management is currently spread across three layers: the bootstrapper generates and writes manifests before FluxCD takes over, FluxCD manages the base operators and infrastructure, and the OpenMCP operators handle service providers, platform services, and cluster providers. This split has served its purpose but means there is no single place where the full operational state of a platform is described.


Suggested change

Lifecycle management is currently spread across three layers: the bootstrapper generates and writes manifests before FluxCD takes over, FluxCD manages the base operators and infrastructure, and the OpenMCP operators handle service providers, platform services, and cluster providers. This split has served its purpose but means there is no single place where the full operational state of a platform is described.

Lifecycle management is currently spread across three layers: the bootstrapper generates and writes manifests before FluxCD takes over, FluxCD manages the base operators and infrastructure, and the different OpenControlPlane operators handle service providers, platform services, and cluster providers. This split has served its purpose but means there is no single place where the full operational state of a platform is described.

maximiliantech · 2026-07-31T13:46:53Z

+
+Lifecycle management is currently spread across three layers: the bootstrapper generates and writes manifests before FluxCD takes over, FluxCD manages the base operators and infrastructure, and the OpenMCP operators handle service providers, platform services, and cluster providers. This split has served its purpose but means there is no single place where the full operational state of a platform is described.
+
+A related pattern is that deployment configuration lives separately from the release artifacts themselves. Operators need to follow external guides to understand how to install or upgrade a given version, rather than the components carrying that information with them.


Suggested change

A related pattern is that deployment configuration lives separately from the release artifacts themselves. Operators need to follow external guides to understand how to install or upgrade a given version, rather than the components carrying that information with them.

A related pattern is that deployment configuration lives separately from the release artifacts themselves. Platform Owners need to follow external guides to understand how to install or upgrade a given version, rather than the components carrying that information with them.

maximiliantech · 2026-07-31T13:54:41Z

+    - id: clusterprovider
+      template:
+        apiVersion: bootstrap.open-control-plane.io/v1alpha1
+        kind: ClusterProviderKind
+        metadata:
+          name: default
+        spec:
+          ocmRepoName: ${schema.spec.ocmRepoName}


@n3rdc4ptn Can you please elaborate why we have a specific RGD called ClusterProviderKind? Why can't we bootstrapping kind: ClusterProvider directly?

maximiliantech · 2026-07-31T14:01:50Z

I get confused by "(Customer) Operator". Can you please use "Platform Owner" @n3rdc4ptn?

maximiliantech · 2026-07-31T14:04:37Z

@n3rdc4ptn Can you please remove landscape specific names from the diagram and instead use something like "us, eu, air-gapped". Please make it more open to understand by anyone in the open source ecosystem.

In general I am bit confused by the lines you have drawed between the boxes. This is more a specific setup rather than a general diagram that shows what is possible, correct?

n3rdc4ptn mentioned this pull request May 7, 2026

Write ADR for Autonomous Platform Clusters openmcp-project/backlog#555

Open

3 tasks

n3rdc4ptn linked an issue May 7, 2026 that may be closed by this pull request

Write ADR for Autonomous Platform Clusters openmcp-project/backlog#555

Open

3 tasks

n3rdc4ptn added 3 commits June 15, 2026 15:43

docs: add ADR for autonomous platform clusters

5c4c752

Signed-off-by: Moritz Marby <moritz.marby@sap.com>

docs: added schematic for rgd based autonomous clusters

802cc3c

Signed-off-by: Moritz Marby <moritz.marby@sap.com>

docs: added first draft of possible bootstrapping

d6ddebf

Signed-off-by: Moritz Marby <moritz.marby@sap.com>

n3rdc4ptn force-pushed the adr-autonomous-clusters branch from e541aba to d6ddebf Compare June 15, 2026 13:43

ValentinGerlach added 4 commits June 18, 2026 11:27

Remove placeholder

0d2858f

Signed-off-by: Valentin Gerlach <valentin.gerlach@sap.com>

docs(adr): improve current state and desired state sections

dac9a14

Signed-off-by: Valentin Gerlach <valentin.gerlach@sap.com>

fix spelling, grammar, and tone

1f9e09a

Signed-off-by: Valentin Gerlach <valentin.gerlach@sap.com>

remove empty immutable-infrastructure ADR

98f07bd

Signed-off-by: Valentin Gerlach <valentin.gerlach@sap.com>

Merge branch 'main' into adr-autonomous-clusters

d252b37

Signed-off-by: Moritz Marby <moritz.marby@sap.com>

n3rdc4ptn marked this pull request as ready for review July 28, 2026 12:19

n3rdc4ptn requested a review from maximiliantech as a code owner July 28, 2026 12:19

maximiliantech requested changes Jul 31, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

docs: add ADR for autonomous platform clusters - #93

docs: add ADR for autonomous platform clusters#93
n3rdc4ptn wants to merge 9 commits into
mainfrom
adr-autonomous-clusters

n3rdc4ptn commented May 7, 2026 •

edited by ValentinGerlach

Loading

Uh oh!

MichaelSp commented Jun 24, 2026

Uh oh!

n3rdc4ptn commented Jul 16, 2026 •

edited

Loading

Uh oh!

maximiliantech left a comment

Uh oh!

maximiliantech Jul 31, 2026

Uh oh!

maximiliantech Jul 31, 2026

Uh oh!

maximiliantech Jul 31, 2026

Uh oh!

maximiliantech Jul 31, 2026

Uh oh!

maximiliantech Jul 31, 2026

Uh oh!

maximiliantech Jul 31, 2026

Uh oh!

maximiliantech Jul 31, 2026

Uh oh!

maximiliantech Jul 31, 2026

Uh oh!

maximiliantech Jul 31, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants


		## Current state

		The current setup uses the `openmcp-bootstrapper` CLI to bootstrap a production installation. Before running it, an operator must manually provision a target Kubernetes cluster, set up a non-empty Git repository, and ensure access to the OCI registry. The bootstrapper then pulls component versions and manifest templates from the OCI registry, generates and writes rendered manifests into the Git repository, and deploys FluxCD to the cluster pointing at that repository. From that point on, FluxCD continuously reconciles the cluster state with what is in Git.


		This means the Git repository is a required external dependency that must be maintained alongside the cluster. The manifests written into it are generated and templated (similar to Helm output), making them difficult to read, understand, or modify by hand. Any configuration change requires re-running the bootstrapper or editing large generated YAML files directly.

		Verifying the setup is also a manual process: an operator must check that FluxCD's `GitRepository` and `Kustomization` resources are in a Ready state, confirm that core components are running in the `openmcp-system` namespace, and create a test `ManagedControlPlaneV2` resource to validate end-to-end functionality.


		Operating the platform across multiple landscapes has shown that the Git repository introduces meaningful overhead. Because manifests are generated from a single large configuration file, they are not easy to inspect or adjust by hand, and any change requires going back through the bootstrapper. This adds friction during initial setup, local development, and for smaller teams who want to operate a landscape without the need for complex configurations.

		Lifecycle management is currently spread across three layers: the bootstrapper generates and writes manifests before FluxCD takes over, FluxCD manages the base operators and infrastructure, and the OpenMCP operators handle service providers, platform services, and cluster providers. This split has served its purpose but means there is no single place where the full operational state of a platform is described.


		Lifecycle management is currently spread across three layers: the bootstrapper generates and writes manifests before FluxCD takes over, FluxCD manages the base operators and infrastructure, and the OpenMCP operators handle service providers, platform services, and cluster providers. This split has served its purpose but means there is no single place where the full operational state of a platform is described.

		A related pattern is that deployment configuration lives separately from the release artifacts themselves. Operators need to follow external guides to understand how to install or upgrade a given version, rather than the components carrying that information with them.

Uh oh!

Conversation

n3rdc4ptn commented May 7, 2026 • edited by ValentinGerlach Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MichaelSp commented Jun 24, 2026

Uh oh!

n3rdc4ptn commented Jul 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

maximiliantech left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

n3rdc4ptn commented May 7, 2026 •

edited by ValentinGerlach

Loading

n3rdc4ptn commented Jul 16, 2026 •

edited

Loading