You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Details about the internals of the reconcile loop will be documented in follow up issues (and addressed in follow up PRs).
Anything else you would like to add:
This could be implemented only after #4908 is completed.
Why a new controller (vs changing existing ones)?
Separation of concerns. The existing controller in CAPI and in the providers should work consistently no matter if a Cluster is originated by a ClusterClass or not. Having a separated controllers enforces this in an implicit way.
Why a dedicated DelegatingClient (vs changing the existing one)?
Because we want to have a strict control on when unstructured types are cached, and we want to avoid this cache to impact on existing controllers.
Why only three watches when there are many other objects kinds in the ClusterClass/Cluster object hierarchy?
For two reasons:
Many of the missing objects are immutable from a ClusterAPI PoV; the only supported way to change them is by rotating object and update references in the higher level object.
Some other objects are not know in advance, like e.g. the ControlPlane, so additional watches will be added dynamically later on when implementing the reconcile loop.
/kind feature
/milestone v0.4
/assign
The text was updated successfully, but these errors were encountered:
Detailed Description
This is part of the activities for the implementation of the ClusterClass proposal.
Managed topologies are going to be managed by a new controller, the ManagedTopology controller.
This controller:
ClusterManagedTopologies
feature flagDetails about the internals of the reconcile loop will be documented in follow up issues (and addressed in follow up PRs).
Anything else you would like to add:
This could be implemented only after #4908 is completed.
Why a new controller (vs changing existing ones)?
Separation of concerns. The existing controller in CAPI and in the providers should work consistently no matter if a Cluster is originated by a ClusterClass or not. Having a separated controllers enforces this in an implicit way.
Why a dedicated DelegatingClient (vs changing the existing one)?
Because we want to have a strict control on when unstructured types are cached, and we want to avoid this cache to impact on existing controllers.
Why only three watches when there are many other objects kinds in the ClusterClass/Cluster object hierarchy?
For two reasons:
/kind feature
/milestone v0.4
/assign
The text was updated successfully, but these errors were encountered: