Introduce Node Lifecycle WG#8396
Conversation
|
/hold |
|
Looks like I'm not a member of kubernetes org anymore. I was a few years back, but didn't keep up with contributions recently. You can remove me as a lead and I can reapply after some contributions to this WG. |
75e1096 to
a19a192
Compare
|
We have had impactful conversations with Ryan about this group and its goals. He has experience with cluster maintenance and I look forward to his participation in the WG. |
|
/cc |
a19a192 to
2d6ac13
Compare
cf8dbfb to
3aed2af
Compare
|
+1 |
|
+1 from SIG Node. SIG Node sponsors this WG with the understanding that the group will concentrate on both - shaping and driving existing KEPs to progress thru stages as well as collecting and evaluating requirements and deciding on priorities for introducing new KEPs. |
|
lgtm from sig-storage |
soltysh
left a comment
There was a problem hiding this comment.
with my sig-apps hat I'll add +1 from sig-apps
See my various comments, also I'm still missing ACK from sig network and sig scheduling
| * Humble Chirammal (**[@humblec](https://github.com/humblec)**), VMware | ||
| * Lucy Sweet (**[@intUnderflow](https://github.com/intUnderflow)**), Uber | ||
| * Krzysztof Wilczyński (**[@kwilczynski](https://github.com/kwilczynski)**), Independent | ||
| * Ryan Hallisey (**[@rthallisey](https://github.com/rthallisey)**), NVIDIA |
There was a problem hiding this comment.
Do we really need that many leads for this WG? Isn't it sufficient to have one per representing company, ensuring they cover all the related sigs?
There was a problem hiding this comment.
We either have represantation of different SIGs or different companies, so I am not seeing any duplicate role at this moment. Perhaps we could trim this list later according to these folks' activity and continued interest?
There was a problem hiding this comment.
Being a lead is a certain responsibility. It goes beyond "is interested in the topic". But I'm okay with letting you figure out among yourself who is really showing up consistently to keep the WG moving and then perhaps do some pruning.
There was a problem hiding this comment.
same concern but overall lgtm
/approve
For Steering.
| mailing_list: https://groups.google.com/a/kubernetes.io/g/wg-node-lifecycle | ||
| liaison: | ||
| github: TBD | ||
| name: TBD |
There was a problem hiding this comment.
@kubernetes/steering-committee we'll need to figure this out prior to merge.
There was a problem hiding this comment.
They can provisionally put me.
I'm happy to and based on load + election timing that makes sense as you mentioned elsewhere.
If anyone objects we can update it.
There was a problem hiding this comment.
Thanks for covering the liaison role @BenTheElder! Added.
|
+1 from SIG Scheduling |
|
|
||
| The following [working groups][working-group-definition] are sponsored by sig-network: | ||
| * [WG Device Management](/wg-device-management) | ||
| * [WG Node Lifecycle](/wg-node-lifecycle) |
3aed2af to
39e3bde
Compare
|
I think we finally have all SIG +1s now? This group will have a lot to do :-) |
soltysh
left a comment
There was a problem hiding this comment.
/lgtm
/approve
/hold
to get sufficient majority from steering
| * Humble Chirammal (**[@humblec](https://github.com/humblec)**), VMware | ||
| * Lucy Sweet (**[@intUnderflow](https://github.com/intUnderflow)**), Uber | ||
| * Krzysztof Wilczyński (**[@kwilczynski](https://github.com/kwilczynski)**), Independent | ||
| * Ryan Hallisey (**[@rthallisey](https://github.com/rthallisey)**), NVIDIA |
There was a problem hiding this comment.
Being a lead is a certain responsibility. It goes beyond "is interested in the topic". But I'm okay with letting you figure out among yourself who is really showing up consistently to keep the WG moving and then perhaps do some pruning.
| ## Timelines and Disbanding | ||
|
|
||
| The working group will disband once the features and core APIs defined in the following | ||
| KEPs/Features have reached a stable state (GA) and ongoing maintenance ownership is established |
There was a problem hiding this comment.
There are no "following KEPs/Features"... so your work is already done? 😛
You probably had this in a different order initially and lost them during some reshuffling. I think this refers to the features under "Prioritization" now?
|
/approve For Steering. https://github.com/kubernetes/community/pull/8396/files#r2161652316 should better get resolved before merging. Also, needs a rebase... |
Co-authored-by: Ryan Hallisey <rhallisey@nvidia.com>
|
Updated and rebased. Thanks everyone! |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: atiratree, pacoxu, pohly, soltysh The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
With 4 steering members +1-ing (Paco, Patrick, Ben and myself) this is good to go as is based on the rules. /hold cancel |
| - Consider improving the pod lifecycle of DaemonSets and static pods during a node maintenance. | ||
| - Explore the cloud provider use cases and how they can hook into the node lifecycle. So that the | ||
| users can use the same APIs or configurations across the board. | ||
| - Migrate users of the eviction based kubectl-like drain (kubectl, cluster autoscaler, karpenter, |
There was a problem hiding this comment.
I am a bit sad that kured was removed here, while it was in the initial comments on a previous issue.
I would like to adapt kured to this framework at least.
There was a problem hiding this comment.
@evrardjp no worries! This list is not supposed to be exhaustive. We will properly explore the migration topic when the time comes.
FYI, kured is still present in https://github.com/kubernetes/community/blob/master/wg-node-lifecycle/charter.md#relevant-projects
| - Explore a unified way of draining the nodes and managing node maintenance by introducing new APIs | ||
| and extending the current ones. This includes exploring extension to or interactions with the Node | ||
| object. | ||
| - Analyze the node lifecycle, the Node API, and possible interactions. We want to explore augmenting |
There was a problem hiding this comment.
I think we could have been more specific here. For example, analyse the possibility to set new conditions onto nodes.
There was a problem hiding this comment.
The WG charter does not replace a proper KEP; it only indicates the direction in which we would like to proceed. So we will even explore options that are not explicitly listed here.
| We expect to provide reference implementations of the new APIs including but not limited to | ||
| controllers (kube-controller-manager), API validation, integration with existing core components and | ||
| extension points for the ecosystem. This should be accompanied by E2E / Conformance tests. | ||
|
|
There was a problem hiding this comment.
CLI might be too broad. Nevertheless we talk about the kubectl above and will also further analyze it in our KEPs.
No description provided.