-
Notifications
You must be signed in to change notification settings - Fork 1.2k
🌱 Controller Lifecycle Management design doc #1192
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
🌱 Controller Lifecycle Management design doc #1192
Conversation
Hi @kevindelgado. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/assign @alvaroaleman |
designs/conditional-controllers.md
Outdated
#### Alternatives | ||
|
||
* A metacontroller or CRD controller could start and stop controllers based on | ||
the existence of their corresponding CRDs. This requires no changes to made to |
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 think the "meta controller" strategy still requires minimal hooks.
7280a4e
to
78b926b
Compare
78b926b
to
712b72f
Compare
designs/conditional-controllers.md
Outdated
* A metacontroller or CRD controller could start and stop controllers based on | ||
the existence of their corresponding CRDs. This puts the complexity of designing such a controller | ||
onto the end user, but there are potentially ways to provide end users with | ||
default, pluggable CRD controllers. More importantly, this probably is not even |
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 think the informer removal doesn't really have anything to do with metacontroller or not, its a requirement regardless of how the add/removal functionality is implemented.
The reason I personally like the metacontroller is that it is event-based, rather than doing polling.
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.
That's fair, I think I was a bit confused on this point. I agree that metacontroller is not an alternative and will update the doc to reflect that.
A discussion of the metacontroller probably belongs in the "Future works / use cases" section rather than in the proposal which is more focused on providing the capability to externally build the metacontroller outside of c-r.
designs/conditional-controllers.md
Outdated
Enable fine-grained control over the lifecycle of a controller, including the | ||
ability to start/stop/restart controllers and their caches by exposing a way to | ||
remove individual informers from the cache and working around restrictions that | ||
currently prevent controllers from starting multiple times. |
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.
Is supporting this in multi-cluster scenarios a goal?
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.
My understanding is that there's isn't anything explicitly preventing a single-cluster solution from working for multiple clusters out of the box. It's sounds like you have specific concerns around this approach not working multi-cluster, is that true?
It's just that because controller-runtime historically has not attempted to support multi-cluster, attempting to use any solution that comes from this effort in a multi-cluster manner would be harder and undocumented.
I think the short answer is no, we aren't looking to fully flesh out a multi-cluster solution here but @DirectXMan12 can chime in if I'm misspeaking
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 guess if this is a generic solution, it doesn't really matter what cluster a given controller talks to (But I can't mark this convo as resolved)
designs/conditional-controllers.md
Outdated
|
||
## Goals | ||
|
||
An implementation of the minimally viable hooks needed in controller-runtime to |
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.
Is an actual implementation of those hooks also a goal or just to provide a hook?
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.
Just providing a hook for now.
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.
But that then achieves your non-goal of supporting start/stop on arbitrary conditions, right?
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.
Supporting start/stop on arbitrary conditions is the goal (which I believe is accomplished just by implementing a mechanism to remove informers and rerun controllers).
Implementing a solution (the actual polling mechanism that does the start/stopping such as a metacontroller or conditional controller) is not the goal.
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.
okay perfect, that wasn't clear to me before. And agreed with #1192 (comment) that metacontroller is not an alternative but more of a follow-up
designs/conditional-controllers.md
Outdated
## Goals | ||
|
||
An implementation of the minimally viable hooks needed in controller-runtime to | ||
enable controller adminstrators to start, stop, and restart controllers and their caches. |
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.
non-goals says that you don't want to add support to start/stop on arbitrary conditions. Please explicitly mention the conditions this is supposed to support
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.
Sorry, I don't think the non-goals are clear, basically I was just trying to say that the goals are just to provide a hook, non-goals are an actual implementation of the hooks.
designs/conditional-controllers.md
Outdated
|
||
### Informer Removal | ||
|
||
The starting point for this proposal is Shomron’s proposed implementation of |
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.
Please describe this a bit, rahter than just saying "This PR explains it", because the PR might change
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.
done
/ok-to-test |
5bb2ab5
to
265a8df
Compare
265a8df
to
ca7439e
Compare
I took a pass at reorganizing, expanding, and addressing feedback on this design. Main updates:
proof-of-concept updated at #1180 I think I've addressed all your feedback from last time @alvaroaleman, let me know if I've missed anything. PTAL |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: kevindelgado The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
fc7d646
to
f4f3ca4
Compare
f4f3ca4
to
f242fff
Compare
@kevindelgado: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
Dusting the cobwebs off this with a new WIP implementation at #1527 |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
@k8s-triage-robot: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Design doc for finer grained controller lifecycle management.