-
Notifications
You must be signed in to change notification settings - Fork 39.9k
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
Daemon design, take 3 #14529
Daemon design, take 3 #14529
Conversation
We found a Contributor License Agreement for you (the sender of this pull request) and all commit authors, but as best as we can tell these commits were authored by someone else. If that's the case, please add them to this pull request and have them confirm that they're okay with these commits being contributed to Google. If we're mistaken and you did author these commits, just reply here to confirm. |
[Copying comment from @bgrant0607 in #14326, for posterity] Re. evolution of this API: Before DaemonSet graduates from experimental, it needs to adopt the more general selector, as discussed in #341. This would be very hard to change later. Before DaemonSet reaches v1beta1, I'd like to see: Rolling update as a service, similar in spirit to Deployment (#1743). For now, pod template updates are forbidden. However, DaemonSet should be declarative and should perform rollouts when its template is modified. I envision DaemonSet creating PodTemplate resources behind the scenes instead of ReplicationController resources. Either integration into the node controller in order to integrate with node lifecycle, such as creation before other pods can be scheduled and implicit forgiveness behavior (#1574), or use of initializers and finalizers (#3585) to achieve the same |
GCE e2e build/test passed for commit 6ec362b. |
GCE e2e build/test passed for commit 0cb5553. |
Daemon design, take 3
This is just #14326 with all of the reviewer comments addressed. (And #14326 was #13368 with all of the reviewer comments addressed.)
ref #1518
@mikedanese @bgrant0607