Task: Implement 'Service Resources Catalog' for existing Service Providers

[Diaphteiros]

Understand the Task

Description

In v2, a user creates an MCPv2 and additional 'service resources' (e.g. Landscaper) next to it. When deleting, the MCP may only be deleted after all services have been removed, because the cluster itself is managed via the MCPv2 resource. However, since in v1, users had to simply delete the MCP resource and all services were removed automatically, it is likely that users will try to remove just the MCPv2 too and not delete the service resources beforehand. This will lead to either of these situations:

• the MCPv2 is stuck in deletion, because the service has a finalizer on the MCPv2 resource which is not removed because the service resource itself is not in deletion
• the service does not have a finalizer on the MCPv2 resource, which means that the cluster will be deleted without the service having been removed, leaking at least an orphaned service resource and potentially even more, depending on the service

Neither of this is desirable. Ideally, the MCPv2 resource would trigger the deletion of all related service resources when it gets its deletion timestamp and then wait until they are removed. Due to our extensibility concept, the MCP controller does not know which service resources could exist though, so there needs to be some kind of 'service resources catalog' that allows it to look up this information.

After some experiments and discussions, we decided for the following approach:

• Each service provider is required to expose its own service resources in the status of its ServiceProvider resource.
  • For example, the ServiceProvider Landscaper should, during initialization, fetch the ServiceProvider resource with the name it got via the --provider-name argument from the platform cluster and add an entry with group landscaper.services.openmcp.cloud, version v1alpha2, and kind Landscaper to its status.resources.
  • This is a list, but it will usually just contain a single entry, unless the same service provider handles multiple services (= service resources).
• Also, when a service provider reconciles its service resource, it must ensure that the corresponding MCPv2 resource has a finalizer in the form of services.openmcp.cloud/<name>, where <name> is the name of the ServiceProvider resource (which the controller got via its --provider-name argument).
  • Example: If the Landscaper ServiceProvider resource is named laas, then each MCPv2 with a Landscaper resource next to it must have a finalizer services.openmcp.cloud/laas.
• During the deletion of an MCPv2, the MCP controller checks all finalizers with the services.openmcp.cloud/ prefix, fetches the corresponding ServiceProvider resources from the platform cluster, checks their exposed resources and triggers the deletion of all of these resources with the same name and namespace as the MCPv2 that is being deleted.

While this adds some unintuitive logic to the service provider contract, it allows users to simply delete the MCPv2 resource without having to worry about its services.

Problem

This is neither documented (I thought I did, but I couldn't find it), nor does any of our existing service providers implement this logic.

The PlatformService MCP (which reconciles the MCPv2 resources) already implements its part of this contract (resource lookup via ServiceProvider resource and triggering their deletion).

Any further valuable resources.

• Original problem discussion in slack: https://sap-ti.slack.com/archives/C095TS1K3CJ/p1753972371176629
• Decision to implement it this way (was taken during a pair programming session): https://sap-ti.slack.com/archives/C095TS1K3CJ/p1754038386972829

What is required to accept the Task as done.

Done Criteria

• Document this, it is a crucial part of the service provider contract.
• Implement for all existing service providers
  • Landscaper
  • Crossplane
• Stretch: Think about whether we want enforce/validate this behavior in service providers and how.
  • Currently, a service provider will work just fine without having this logic implemented, it will only cause problems during deletion. Maybe it would be a good idea preventing a service from working if this contract isn't met?
    • An idea would be to not grant AccessRequests for the MCP cluster if the finalizer is not there and the service resources are not exposed in the ServiceProvider's status, but this is not trivial to do.
• Present in review.

[reshnm]

@Diaphteiros Can we please exactly specify the format of the status?

Something like this?

status:
   managedTypes:
   - group: landscaper.services.openmcp.cloud
     version: v1alpha2
     kind: Landscaper

[reshnm]

Also, regarding point 2: Adding a finalizer to the ManagedControlPlaneV2 resource would mean that each service provider knows the ManagedControlPlaneV2 and that we would need to keep them in sync. when updating the ManagedControlPlaneV2 version.
If the ps-mcp controller already knows all service instance GVKs, would we still need a finalizer for each service instance?
The ps-mcp could still delete the service instance resources and only start deleting the ManagedControlPlaneV2 when all service instance resources are gone. It seems like we are applying references in both directions, which we could avoid.

[Diaphteiros]

The format of the status is defined by its API struct: https://github.com/openmcp-project/openmcp-operator/blob/main/api/provider/v1alpha1/serviceprovider_types.go#L34

The field is currently named resources, but we could rename it to something else, I just had to pick a name so that I could implement the MCP controller logic.

In theory, each service provider should anyhow check for MCP existence, because it should not do anything if a service resource is created without a corresponding MCP. Or if the MCP is in deletion, for example. If the service provider does that, also ensuring the finalizer is not much additional effort.
You are right though, we could do it without the finalizer. The MCP controller could check for all service resources, even without having the finalizer.

[reshnm]

The format of the status is defined by its API struct: https://github.com/openmcp-project/openmcp-operator/blob/main/api/provider/v1alpha1/serviceprovider_types.go#L34

The field is currently named resources, but we could rename it to something else, I just had to pick a name so that I could implement the MCP controller logic.

That is fine, I didn't know that this is already there. We can keep it like this.

[reshnm]

In theory, each service provider should anyhow check for MCP existence, because it should not do anything if a service resource is created without a corresponding MCP.

We implicitely did that by only creating an access request on the MCP cluster without a cluster request. But maybe we should make this more explicit

[Diaphteiros]

We implicitely did that by only creating an access request on the MCP cluster without a cluster request. But maybe we should make this more explicit

My argument is that not even the AccessRequest should get created if the MCPv2 doesn't exist. Although it is nice that even without this check the service provider is unable to do much.

[Diaphteiros]

I thought about it and it would probably be a good idea to have the mcp operator scan for all service resources, independently from any finalizers. Because this way, we won't end up with orphaned services, even if a service provider 'forgets' to add the finalizer. This would make the finalizer optional.

This requires a code change in the PlatformService MCP too, but it should be easy.