Placeholder to discuss how we want to proceed with ProviderConfig.
What would you like to be added:
I am wondering if we could drop the ProviderConfig completely in context of reworking the release channel / platform registry.
Why is this needed:
This would simplify service provider development and operations and reinforce the concept of managed services over 'highly customizable installers'.
Impact on the template:
The ProviderConfig would be dropped from the ServiceProviderReconciler interface. Instead of fetching and providing it as a reconcile context parameter and having each ServiceProvider implementation check things like image versions, this could move into the generic SPReconciler logic, just like cluster handling.
Drift detection (PollInterval) could instead be implemented as a service provider command line argument or env variable.
etc tbc...
Placeholder to discuss how we want to proceed with
ProviderConfig.What would you like to be added:
I am wondering if we could drop the
ProviderConfigcompletely in context of reworking the release channel / platform registry.Why is this needed:
This would simplify service provider development and operations and reinforce the concept of managed services over 'highly customizable installers'.
Impact on the template:
The
ProviderConfigwould be dropped from theServiceProviderReconcilerinterface. Instead of fetching and providing it as a reconcile context parameter and having each ServiceProvider implementation check things like image versions, this could move into the generic SPReconciler logic, just like cluster handling.Drift detection (PollInterval) could instead be implemented as a service provider command line argument or env variable.
etc tbc...