-
Notifications
You must be signed in to change notification settings - Fork 531
Component configuration for controller #114
Comments
The current set of common parameters required by controllers is captured in ControllerConfig struct. Sourcing this configuration from a configmap or other api resource would allow out-of-tree components to discover this configuration rather than having to duplicate it, and allow |
I think it can be organized as a new
The behavior should be:
The advantages from my point of view is the validation and better extendibility. |
@xunpan I have a couple of comments:
feature-gates:
- name: push-reconciler
enabled: true
|
I also have question:
|
@xunpan For your 3.
My thinking is that provision of yaml via -f would be to support running the controller manager outside of a kube cluster (e.g. for testing). As you say, the use cases within the cluster are both exposing configuration to agents other than the controller manager (e.g. kubefed2 discovering configuration) as well as configuring the controller manager.
In a world with a single federation control plane and no other consumers of clusters, it might make sense to have clusters only in the same namespace. But if more than one federation control plane (namespaced or otherwise) exists in a cluster, it may make sense to share a namespace containing available clusters. And if there are consumers of clusters other than federation - and its been suggested that this is the case - there is an added need to support a configurable cluster namespace. That said, I think it might make sense to default the registry namespace to the federation namespace rather than kube-multicluster-public, so long as any given deployment can choose to override that decision. cc: @pmorie
As per recent breaking API changes, I think deprecation before we go beta is simply removal. That means we have a limited window left to do this kind of invasive work. |
Follow up actions:
|
A couple notes here while they're in my head: I think one input to determining what the shape of the eventual config API is knowing the outcome of #688. The right granularity for configuration APIs seems like one per functional area. That would yield:
Having distinct APIs for different functional areas would make it easier to evolve and version config APIs independently, which is desireable. |
The only options we set today are for all controllers - there are no options specific to the functional areas you mention. |
A couple notes here while they're in my head: I think one input to determining what the shape of the eventual config API is knowing the outcome of #688. The right granularity for configuration APIs seems like one per functional area. That would yield:
Having distinct APIs for different functional areas would make it easier to evolve and version config APIs independently, which is desireable. |
Whoops - did not mean to close this. |
Work is ongoing to implement support for |
Yes, I think this can be closed. Thank you! |
Follow-on to #101; this is to add (where it makes sense) additional configuration parameters beyond basic feature gating. For example: the push reconciler is enabled/disabled by feature gate, but the resync duration for the push reconciler would be configured by a distinct component configuration API field mapped to a CLI flag.
The text was updated successfully, but these errors were encountered: