[Feature] Allow installation of Services with custom helm installation values

[GenosseOtt]

Context

As a team using ControlPlane and installing its services,

I sometimes require custom parameters to be set during installation.

I am fully aware this means the component is no longer managed and I have to ensure my parameter configuration also works on future versions of the operator below before upgrading.

@maximiliantech as we spoke about this one - lets think of an unmanaged way/approach to install managed services.

Use case

• As a team using Flux ServiceProvider, I want to pass param during flux installation as I need the operator to utilize this feature to use GitOps on external Workload CLusters this control plane orchestrates
• @enrico-kaack-comp please edit accoriengly and link the param we came across

Out of scope

[maximiliantech]

Note to myself and @christophrj: This issue goes into the direction to potentially support multiple ProviderConfigs of a Service Provider to offer different installation options of a Service on an end user ControlPlane.

An example could look like this:

Minimal Flux installation

apiVersion: flux.services.open-control-plane.io/v1alpha1
kind: ProviderConfig
metadata:
  name: flux-base
spec:
  versions:
    - version: "2.8.3"
      chartVersion: "2.18.2"
      chartUrl: "oci://ghcr.io/fluxcd-community/charts/flux2"
      # values: # no custom values - default helm chart installation

High End Flux installation

apiVersion: flux.services.open-control-plane.io/v1alpha1
kind: ProviderConfig
metadata:
  name: flux-full
spec:
  versions:
    - version: "2.8.3"
      chartVersion: "2.18.2"
      chartUrl: "oci://ghcr.io/fluxcd-community/charts/flux2"
      values:
         # enable ALL controllers
         # enable all feature flags etc.

Verdict

The service provider pattern does not support multiple ProviderConfigs right now mainly because the end user can not specify which presets are available or how this can be selected.
Maybe the ProviderConfig is not the best way to configure this. A separate API might be wise?!

We should also look at this feature with the perspective of releasechannel V2. What are your thoughts @n3rdc4ptn?

[christophrj]

apiVersion: flux.services.open-control-plane.io/v1alpha1
kind: ProviderConfig
metadata:
  name: flux
spec:
  versions:
    - version: "2.8.3-base"
      chartVersion: "2.18.2"
      chartUrl: "oci://ghcr.io/fluxcd-community/charts/flux2"
      # values: # no custom values - default helm chart installation
    - version: "2.8.3-full"
      chartVersion: "2.18.2"
      chartUrl: "oci://ghcr.io/fluxcd-community/charts/flux2"
      values:
         # enable ALL controllers
         # enable all feature flags etc.

@maximiliantech I slightly adjusted your example to demonstrate how flux or eso currently support defining multiple (pseudo) versions with different helm values.

@GenosseOtt mapping this to our personas, is it sufficient if the platform owner defines presets for end-user to consume or do you want to enable end-users to freely choose any installation parameter? I'm afraid I don't understand the idea/benefit of an unmanaged service provider offering yet.

[christophrj]

We could also address this by implementing the managed to unmanaged transition that is mentioned in the serivce provider design doc:

SoftDelete platform concept. A managed service can transition to a unmanaged service by soft deleting its corresponding ServiceProviderConfig without losing the DomainService. This way a tenant could offboard itself partially or entirely from the platform without losing the provisioned infrastructure.

This is only feasible for services that are deployed on the tenant control plane though (which we eventually want to get rid of completely).

But it feels kind of odd to use a service provider if a tenant wants an unmanaged service from the beginning.

[GenosseOtt]

@christophrj / @maximiliantech thanks for the quick evaluation and feedback.

We do not have a set answer to this request.
Intention of this issue/request was exactly to catch and collect such considerations.

Lucky us, we have a stakeholder among us - @enrico-kaack-comp - who came across this need in a larger end-user facing setup.

Following topics lets explore - curious to hear your proposals.

• "enable end-users to freely choose any installation parameter"
• naming of this "free-param [un-]managed" installation style

:-)