Implement OCM `Discovery` API to look-up available versions

[maximiliantech]

What would you like to be added?

Add the Discovery API to the runtime, so that every service-provider can look-up available versions via the Discovery API instead of their own ProviderConfig.
Changes should include:

• create meaningful functions that service providers can use to know available services, providers, artifacts, components
• service providers shall create/update/delete their own Discovery API
• the ProviderConfig will store the necessary information about the components the service provider will watch (e.g. "providers") - no specific versions of component details anymore

Why is this needed?

With ADR: Discoverable Components, we have agreed to use OCM for the discovery of available services that an End User can choose when ordering a ControlPlane.

Related stuff

Prototype implementation: openmcp-project/service-provider-crossplane#228

[christophrj]

The sample implementation contains label selectors for the Discovery objects but not the components within a ReleaseChannel. My understanding is that OCM components will be labeled as well in the ReleaseChannel to decouple the implementation from a specific setup that a developer can't know upfront.

Let's try to clarify the discovery usage from a service provider developer view. As a developer I know which artifacts (OCI images, Helm charts and credentials) I need to implement my service and I want to use the new discovery functionality to resolve them from the release channel. I don't know how the release channel is set up and my service provider needs to work with all kinds of release channel instances.

Example Flow

F.1: As a service provider developer, I create a new service and specify the component identifiers (OCM component label selectors) that my service will use to discovery every required component from the release channel. I allow platform owners to adjust the component labels through the ProviderConfig to decouple my implementation from a specific release channel.

E.g. for service-provider-crossplane I create two component identifiers: a) to discover the Crossplane Helm chart and b) to discover Crossplane providers. I use the these identifiers to create Discovery objects for each required (set of) component(s).

Note that this is slightly different compared to the discovery label selector of the sample implementation which are not required if the service provider creates the Discovery objects.

F.2: As a service Provider developer I rely on the OCM Discovery API to expose the available versions of the components that I requested. For development, E2E tests use manually created Discovery objects without a ReleaseChannel. Eventually I release a deployable version of the Service Provider.

F.3: As a platform owner I deploy the released version of the service provider and either adjusts the component identifier defaults to match the expected components in the platform's release channel or labels the OCM components to match the service provider defaults.

Implications

I.1: A service provider (developer) owns the Discovery objects and is responsible for defining OCM component label selectors and exposing them to the platform owner through the ProviderConfig.

I.2: The platform owner owns the ReleaseChannel and is responsible to label OCM components in a release channel for service providers to resolve their required artifacts.

I.3: Discovery API selectors are not required int the ProviderConfig.

@n3rdc4ptn @maximiliantech Does that sound reasonable to you?

Discovery Package (Draft)

A very basic discovery package could look like this:

// create a Discovery object for each component identifier in the config. A component identifier is the OCM component label selector to discover a component.
r, err := discovery.NewResolver(config)

// retrieve e.g. the Crossplane helm chart URL of a specific version from the Disovery.status. ComponentId is one of the identifiers provided when creating the resolver. Requested version is from the current (OnboardingAPI) request context. The service provider knows which OnboardingAPI version field relates to which componentId.
discoveryResult, err := r.Discover(componentId, requestedVersion)

testutils:

err := discovery.Setup("esoHelmChart", "2.1.0", "oci://ghcr.io/external-secrets/charts/external-secrets") 

Goal

A service provider developer does not require any knowledge about how OCM works or what a ReleaseChannel is. Developers only use a yet to be implemented discovery module/package that provides the necessary functionality (including helpers for testing).