Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement scaffolding for the ManagedTopology controller #4933

Closed
fabriziopandini opened this issue Jul 13, 2021 · 0 comments · Fixed by #4965
Closed

Implement scaffolding for the ManagedTopology controller #4933

fabriziopandini opened this issue Jul 13, 2021 · 0 comments · Fixed by #4965
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Milestone

Comments

@fabriziopandini
Copy link
Member

fabriziopandini commented Jul 13, 2021

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:

  • Must be behind a new ClusterManagedTopologies feature flag
  • Must use the same cache of the other controllers
  • Must have a new dedicated DelegatingClient using the same cache and enforcing caching for unstructured types
  • Must watch for
    • Cluster (the type of Object being reconciled)
    • ClusterClass
    • MachineDeployments
  • Must have RBAC access for above objects and
    • groups=infrastructure.cluster.x-k8s.io;bootstrap.cluster.x-k8s.io;controlplane.cluster.x-k8s.io,resources=*,verbs=get;list;watch
    • groups=apiextensions.k8s.io,resources=customresourcedefinitions,verbs=get;list;watch

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants