openmcp-project / openmcp-project/backlog

Design Document: Deploy Service Provider as Platform Service

Open
#369 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

kind/feature-request needs/validation sig/core sig/extensibility
Dominant language
No language data
Stars
1
Forks
0
PR merge metrics
No merged PRs in 30d

Description

Understand the problem

In our openMCP ecosystem, we have the concepts around Cluster Providers, Service Providers and Platform Services. Each of these providers serve a different use case in our platform ecosystem.

There are several tools, were one could argue that we would need both Service Providers and Platform Services for it.
Examples:

  • Flux
  • ESO
  • metrics-operator
  • cert-manager
  • Velero
  • custom root CA service

We all agree that it would not make sense to build for each tool a Service Provider AND a Platform Service since the only difference would be the deployment of the operator and its CRDs.

Context

We should work on a design document that covers this case. Let's think how we can best include this use case in our ManagedControlPlane offering.

💡 An idea would be to run a Service Provider as Platform Service. We would reuse the Service Provider image but deploy this image as Platform Service.
It could look like this:

apiVersion: openmcp.cloud/v1alpha1
kind: PlatformService
metadata:
  name: eso
spec:
  image: ghcr.io/openmcp-project/images/service-provider-eso:v1.0.0

Through some configuration in the Platform Service or via environment variables, we could configure the provider the way we want to deploy and run the image (CRDs end up in the platform cluster as well as the provider pod).

We should dig a little bit deeper of how this can be achieved since Flux would be right now the only open source tool where we would foresee a chicken-and-egg-problem and where this concept might not be suitable (which is okay as well).

❗ IMPORTANT: This task would be just the first task to document the overall idea of the concept. Naturally, out of this design document more tasks would follow to determine concrete implementation work.

Proposal Acceptance Criteria
  • Agree on a concept in the core developer round
  • Write down concept as design document in our open source documentation
How much traction does this feature have?

There is an intrinsic motivation from core development team to solve this problem to further strengthen the concepts and the flexibility of our openMCP ecosystem.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue names no files or tests; start by reviewing the existing Service Provider and Platform Service concepts in the openMCP documentation. Compare the proposed deployment model with the listed examples, especially Flux, then document an agreed concept and record the limitations and follow-up implementation work.

Written by the indexing model from the issue text.

Assessment

Domain
documentation, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.