In what area(s)?
/area API
Describe the feature
Currently, all of our configuration relies on well known ConfigMaps placed next to our control plane. The components pick up the config in those ConfigMaps through an informer on ConfigMaps and they then parse the map[string]string typed data into a struct which is then used by the individual components.
This is all nice and it works in principle. It has a few drawbacks though:
- Discoverability. We place a huge
_example block at the top of each ConfigMap that is supposed to document the available keys. A ton of users stumbled over this and it's arguably a hacky way of providing documentation.
- Typing. Related to the above, typing is done through parsing and thus the expected schema needs to be documented.
- Compatibility guarantees. Are there any? I think we have tried to not break backwards compatibility on the config, at least in Serving but I'm not sure if we technically have any guarantees here.
Config CRDs
Instead of ConfigMaps, we could use Configuration CRDs, i.e. CRDs that represents the same data as the ConfigMaps do today, but in a structured way, for example AutoscalerConfiguration, DeploymentConfiguration etc. They could have an openAPI schema, telling the user directly which fields are supported and what format we expect in them. Their APIs can be versioned just like any other API we ship, making it easier to do controlled breaking changes while giving clear guarantees on compatibility.
This is especially important for the operator. Currently, we ship the operator with a spec.config field which is map[string]map[string], a map of maps, each able to represent a ConfigMap's content. Essentially, by putting this in the operator API, we kinda commit to a certain schema (maybe not because it's a map of maps and it's willynilly but you get the idea).
Having versioned Configuration APIs in the upstream (Knative Serving in this case) would be great wrt. guarantees and construction for the API as a whole.
Further down the line, this could potentially also open up the possibility to define per-namespace configuration as proposed in #7711. Generally agreeing on Configuration CRDs across the project would probably make per-namespace configuration trivial as it'd mostly come down to scoped informer calls to fetch the respective configuration for a given resource. But that's a stretch goal.
In what area(s)?
/area API
Describe the feature
Currently, all of our configuration relies on well known ConfigMaps placed next to our control plane. The components pick up the config in those ConfigMaps through an informer on ConfigMaps and they then parse the
map[string]stringtyped data into a struct which is then used by the individual components.This is all nice and it works in principle. It has a few drawbacks though:
_exampleblock at the top of each ConfigMap that is supposed to document the available keys. A ton of users stumbled over this and it's arguably a hacky way of providing documentation.Config CRDs
Instead of ConfigMaps, we could use Configuration CRDs, i.e. CRDs that represents the same data as the ConfigMaps do today, but in a structured way, for example
AutoscalerConfiguration,DeploymentConfigurationetc. They could have an openAPI schema, telling the user directly which fields are supported and what format we expect in them. Their APIs can be versioned just like any other API we ship, making it easier to do controlled breaking changes while giving clear guarantees on compatibility.This is especially important for the operator. Currently, we ship the operator with a
spec.configfield which ismap[string]map[string], a map of maps, each able to represent a ConfigMap's content. Essentially, by putting this in the operator API, we kinda commit to a certain schema (maybe not because it's a map of maps and it's willynilly but you get the idea).Having versioned Configuration APIs in the upstream (Knative Serving in this case) would be great wrt. guarantees and construction for the API as a whole.
Further down the line, this could potentially also open up the possibility to define per-namespace configuration as proposed in #7711. Generally agreeing on Configuration CRDs across the project would probably make per-namespace configuration trivial as it'd mostly come down to scoped informer calls to fetch the respective configuration for a given resource. But that's a stretch goal.