2023 Annual Report: SIG Node

[palnabarun]

2023 Annual Report: SIG Node

Chairs: @SergeyKanzhelev @mrunalp
Liaison: @pacoxu

Actions for the chair/organizer of the community group:

• Consult your community group to complete draft of report
• If needed, consult with Steering Committee liaison on any private issues or concerns that arrise while completing report
• Submit PR to git.k8s.io/community repo with copy of report, assigning your Steering Committee liaison for review
• Steering Committee reviews report, and may make comments/ask questions
• Once all comments are addressed, Steering Committee will approve report to merge
• If needed, any follow up items may be brought to the "Chairs, Tech Leads, and Organizers" meeting in April

Once all the above items are complete, this issue may be /close'd

Key dates:

• Initial PR to communtiy repo should be opened by May 1, 2024
• PR should be reviewed and merged by May 22, 2024

More detailed information on the annual reports process is available here.

Your group's report template is available here: https://git.k8s.io/community/sig-node/annual-report-2023.md

If you have any questions or concerns about this process, you may reach the Steering Committee via the following methods:

• Slack/E-mail your liaison directly
• The public #steering-committee channel in Slack
• The public mailing list steering@kubernetes.io
• The private mailing list steering-private@kubernetes.io for any private or sensitive issues.

/assign @SergeyKanzhelev @mrunalp
/sig node
/committee steering
/area annual-reports

[SergeyKanzhelev]

@palnabarun how was the list of KEPs generated?

I see that this list https://github.com/kubernetes/community/blob/master/sig-node/annual-report-2023.md includes

4188 - New kubelet gRPC API with endpoint returning local pods information - v1.29

which was never released in 1.29.

Is there a chance the list be regenerated with the proper metadata?

[palnabarun]

@SergeyKanzhelev The data is generated from KEP metadata (kep.yaml) that accompanies every KEP. In the k/enhancements repo, I see the KEP has Alpha milestone set to 1.29. That is the source of error.

Please feel free to remove any erring KEPs from the report and follow up on fixing the metadata.

[SergeyKanzhelev]

@SergeyKanzhelev The data is generated from KEP metadata (kep.yaml) that accompanies every KEP. In the k/enhancements repo, I see the KEP has Alpha milestone set to 1.29. That is the source of error.

Please feel free to remove any erring KEPs from the report and follow up on fixing the metadata.

The KEPs being approved, but then removed from the milestone quite often. There is no alternative milesetone to assign them now as the milestone has passed and there may not be anybody taking it right away to the next one.

Since there may be other KEPs like this, any chance automation can be improved to handle those cases?

[palnabarun]

There is no alternative milesetone to assign them now as the milestone has passed and there may not be anybody taking it right away to the next one.

The milestones can be removed if KEP is not targeted anymore to a specific one.

The automation takes the KEP metadata as source of truth. That was the intended use case. Not sure what other information can feasibly be used in the automation.