Implement Landscaper Service Provider

[In-Ko]

Description

An MCP Service Provider for the Landscaper needs to be implemented.

https://github.com/openmcp-project/service-provider-landscaper

Step 1: Deployment of one service instance

• Implement the installation/update/deletion of single landscaper instances.
• In this step we assume that workload cluster, mcp cluster, ingress controller exist.
• Clarify which configuration parameters a landscaper instance has.

Step 2: Landscaper Provider

• Define Landscaper resources, which describe the landscaper instances.
• Implement controller of the landscaper service provider.
• Retrieve workload cluster via ClusterRequest.
• Retrieve mcp cluster (referenced in Landscaper resource)
• Ingress controller (via a platform service?)
• Deploy instance (step 1)

Step 3: Setup Landscaper Provider within an MCP landscape

• Define ServiceProvider resource and its configuration for a Landscaper Provider

Done Criteria

• ...
• Code has been reviewed by other team members
• Internal technical Documentation created/updated
• New / changed code is documented
• Unit Tests created for new code or existing Unit Tests updated
• Integration Test Suite updated
• Enduser Documentation updated (if applicable)
• Successful demonstration in Review

[robertgraeff]

• A basic create/update and the delete logic for a single landscaper instance is implemented (using a fixed workload cluster and a fixed mcp cluster).
• The Landscaper resource is defined. It needs/allows no configuration by the user, i.e. the spec of a Landscaper resource is empty. The list of deployers is fixed, everyone gets the helm and manifest deployer.
• Move code to open source git repository github.com/openmcp-project/service-provider-landscaper.
• Build: embed repository github.com/openmcp-project/build; create taskfile
• Set up github actions.
  • A first build succeeded: tag v0.0.2
  • Component and image are available on openmcp-project/packages
• The config parameters should be organized more clearly (the parameters which correspond to the old helm values). Different types of config:
  • Provider configuration in the ServiceProvider resource, e.g. the landscaper version, and the images for landscaper, webhooks, and deployers.
  • Instance configuration in the Landscaper resource of the user. (There is no config so far.)
  • Instance configuration for technical settings that are not set by the user (e.g. resource limits).
• The access to the MCP cluster and workload cluster must be implemented.
  • For the MCP cluster, the MCP resource must be read.
  • For the workload cluster, a ClusterRequest resource must be created. It must be waited until the cluster is available. During a delete operation, the ClusterRequest must be deleted.
• RBAC resources are currently created in the way as the helm charts did. This will be adjusted when access is provided per AccessRequests.
• Use controller-utils library for clusters to load kubeconfigs and create clients.
• Use controller-utils library for status conditions.
• Readiness check for the deployments of the landscaper.
• Ensure existence of the Landscaper custom resource on the onboarding cluster.
• Migrate from Ingress to Gateway. (low priority)

[In-Ko]

Moved to "on hold" for now, since it is required to get a preliminary "Cluster Scheduler" and "openMCP Operator" out of the door to test the integration.

[reshnm]

Updated July 4

Most of the functionality of the service provider landscaper is now implemented.
Unit-Test are now working.
Pull request is merged: openmcp-project/service-provider-landscaper#57
The git repo is now public.

There are a few last steps missing, that are depeing on the following:

• How will the integration with a MCP resource work (for that to test, we need to have the MCP Operator working in conjunction with our V2 landscape)
• How will the DNS handling work for the Landscaper ingress/gateway objects. The sp-landscaper has currently no way to know what DNS addresses shall be used for the webhook ingress objects. There needs to be a generic way in V2 to obtain such information.
• Currenty the sp-landscaper is creating its own unique id to create namespaces on the workload cluster. Should there be a generic way to obtain such a unique id for service providers that can be used to create unique resource names on the workload cluster.

[In-Ko]

• depends on the availability of Implement OpenMCP internal DNS Platform Service #95 and Implement Gateway Platform Service #43

[In-Ko]

DNS is ready and likely, Gateway will be getting ready in the coming sprint.
So we should include this Landscaper-specific task also in the sprint.