docs(design): service provider

[christophrj]

What this PR does / why we need it:
This document outlines the ServiceProvider domain and its technical considerations within the context of the openMCP project, providing a foundation for understanding its architecture and operational aspects.

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

Special notes for your reviewer:
General RFC

Release note:

high level service provider documentation

[reshnm]

Regarding ProviderConfigs:

ProviderConfig should only contain service provider internal configuration which can be used by a landscape operator to configure the service provider to the specifics of the landscape.

The shall not be used to

• (a): Configure available versions/locations of the DomainService provided by a service provider
• (b): provide information to consumers of the service provider api (this is why they are stored on the platform cluster)

Currently we are violating rule (a). This is because there is no "release-channel"/"marketplace" API available that would provide this information for all service providers. However, this is where we want to go in the mid to long term.
This would also release the burden of the landscape operator to configure the ProviderConfigs "statically" during deployment.

"release-channel"/"marketplace" API would be available for both the service providers and the consumers of the service provider api.

[maximiliantech]

I love this document!! 🚀
I have some minor comments. What do you think?

[maximiliantech]

That's great! I like the changes. That definitely makes it more precise. 👍

[jakobmoellerdev]

Sorry the review took longer than expected. I have two major grypes with this one. I read through the doc but honestly it was very high level. I did not get a lot of actual design conclusions from it, but that may just be me

1. As I understand theres gonna be an additional library on top of controller runtime. I would love if we can keep as much as possible a low level integration and we can orchestrate cluster access ourselves
2. I would love to understand technical implications of the runtime abstraction and I need to understand how we will actually code a multi-runtime abstraction on top of our existing controllers

[christophrj]

Sorry the review took longer than expected. I have two major grypes with this one. I read through the doc but honestly it was very high level. I did not get a lot of actual design conclusions from it, but that may just be me

1. As I understand theres gonna be an additional library on top of controller runtime. I would love if we can keep as much as possible a low level integration and we can orchestrate cluster access ourselves
2. I would love to understand technical implications of the runtime abstraction and I need to understand how we will actually code a multi-runtime abstraction on top of our existing controllers

Hi @jakobmoellerdev thanks for the feedback. the doc is supposed to be very high level and imo should stay that way but things should get clearer as soon as we have the service provider template ready. Then we can iterate over all the technical details