-
Notifications
You must be signed in to change notification settings - Fork 38.7k
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
Encapsulate KCM controllers with their metadata #120371
Encapsulate KCM controllers with their metadata #120371
Conversation
type serviceAccountTokenControllerStarter struct { | ||
rootClientBuilder clientbuilder.ControllerClientBuilder | ||
// RegistrableController map so that it can always run first. | ||
func newServiceAccountTokenRegistrableController(rootClientBuilder clientbuilder.ControllerClientBuilder) *registrableController { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we move this controller to a new file?
cc people from the last PR: @liggitt @nckturner @aojea @cici37 @alexanderConstantinescu @msau42 @jprzychodzen @soltysh @andrewsykim @cheftako @thockin @sftim |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was just a skim, but I personally like the direction. I'd emphasize the encapsulation by segregating this code behind a clean API (even if in the same pkg, but a different file) and making the code that calls it as simple and streamlined as possible.
/triage accepted |
c40db78
to
eca4ea1
Compare
as a result of the discussions, I have made the following changes:
|
return &ControllerDescriptor{ | ||
name: names.ValidatingAdmissionPolicyStatusController, | ||
initFunc: startValidatingAdmissionPolicyStatusController, | ||
requiredFeatureGates: []featuregate.Feature{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don´t have the feeling this is a good idea, because right now it looks pretty neat and clean, but as soon as the code evolves and new features are added this is just yet another place to update the feature gates ... or what happen if the controller has only one part of the logic with a feature gate? we need to run the controller and we still need to add a feature gate inside the controller logic
some food for thoughts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It depends on what tradeoff we want to make. If we want to have all the controller metadata and logic sprinkled everywhere or together. We already have feature gate logic sprinkled everywhere, so IMO this would not change that much. That is, one has to search for all occurrences of a feature gate to get the full picture.
or what happen if the controller has only one part of the logic with a feature gate? we need to run the controller and we still need to add a feature gate inside the controller logic
I think we would solve this the same way we do today. We can put a feature gate call inside the init function or inside the controller itself.
For the usual cases, we could reason about controllers without running them. That is, we could for example show which controllers are gated by which feature gates in kube-controller-manager's help
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the logic is always going to be sprinkled everywhere, the feature gated code can be anything, a function or just part of a function ...
For the usual cases, we could reason about controllers without running them. That is, we could for example show which controllers are gated by which feature gates in kube-controller-manager's help
I think that the intent is good, but I'm afraid that the reality is different and it soon will get out of sync and we'll have an additional place interacting with the code that is not obvious for everybody
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know it only helps a little, but I have added a unit test to make sure people do not mix the old and the new approach.
/test pull-kubernetes-conformance-kind-ga-only-parallel |
#119208 shows a use case for this refactoring and #119208 (comment) discusses how controller name should be consumed. |
@thockin could you please review again? |
280db77
to
c3b3fb6
Compare
rebased |
c3b3fb6
to
c91e15f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
really minor questions
- These metadata can be used to handle controllers in a generic way. - This enables showing feature gated controllers in kube-controller-manager's help. - It is possible to obtain a controllerName in the InitFunc so it can be passed down to and used by the controller. metadata about a controller: - name - requiredFeatureGates - isDisabledByDefault - isCloudProviderController
… to make it more generic - pass a map of controllerDescriptors instead of a function
…ollers into StartController function the function is reused by ServiceAccountTokenController
- controller descriptors should not be feature gated - aliases should not be defined for new controllers and have only a canonical name
c91e15f
to
1591a0e
Compare
Thanks! /lgtm |
LGTM label has been added. Git tree hash: 2652230cbcb0ffbf6673bdab4f6cb7022ae35a07
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: atiratree, thockin The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Thanks for the review @thockin. Unfortunately I missed controllers enabled by default in one test case. And just ran into it during a review #119208 (comment). I have opened a small PR for this: #121611 |
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
this is a followup to following PR and a discussion: #115813 (comment)
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
similar thing can be done for cloud-controller-manager, but it is better to open a new separate PR for that
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: