WG Component Standard Needs Your Help - Mentorship Available
Michael Taufen
Dear contributors,
The Component Standard Working Group needs your help.
This working group exists to develop a standard foundation for core Kubernetes components to build on top of. There have been many efforts to standardize in the past, and the working group puts them, and standard code, in one place. If you'd like to learn more about our working group, check out our README, drop by our weekly meeting (Tues 8:30am PT), and hit us up on Slack (#wg-component-standard) or our mailing list.
We have several important lines of work, most of which are in need of additional contributors. Our subprojects cut across all core Kuberentes components and often involve working with multiple SIGs. If you are looking to dive in deep and significantly increase your involvement in the Kubernetes project, this is a great way to do so.
We have active mentors available to help new contributors to our working group. Two of our active subprojects (@alejandrox1 experimenting with the legacyflag library, @obitech bringing strict decoders to ComponentConfig) are currently being driven by new contributors, with mentorship from our WG chairs. We want to help you help us, and if you can commit to any of our active areas of work, we will mentor you.
Our most active subprojects are working on improving the config surface of core Kubernetes components:
ComponentConfig Ergonomic lmprovements
Summary: ComponentConfig moves our core binary configuration from flags to versioned, structured config files. This makes it much easier to manage our many configuration APIs. There are several fundamental areas of ComponentConfig that still need improvement, including making backwards-compatible flag migrations easier, deciding how to deal with platform-specific and instance-specific config, work on decoders specific to ComponentConfig, making it easier to test config APIs, and more.
Flag to Config Migrations
Summary: Though many components now expose ComponentConfig APIs, most still have options that are only available via flags. In order for ComponentConfig APIs to graduate to GA and deprecate flags, these options need to be made available in the config in a backwards-compatible way. While we have been incrementally moving options for a long time, we need to accelerate this work, and we need contributors to help. There is work to be done in all core Kubernetes components, including kubelet, kube-proxy, API server, scheduler, and controller-manager.
If you are interested in working in these areas and would like mentorship, please reach out to our chairs (@mtaufen, @stealthybox, @sttts) on our Slack (#wg-component-standard) or our mailing list. You can also check out the recording of a New Contributor Onboarding session we ran in July.
There are several other areas our working group is scoped for, but has not had the bandwidth to focus on yet. These include making it easier for a component to set up a standard HTTPS server with delegated auth that exposes common observability endpoints and improving klog. If you are interested in contributing to or leading standardization/refactoring efforts in these or other areas, we're happy to host you in our working group. While we can't promise technical mentorship for areas we haven't focused on yet, if it fits our scope we can help you get organized and provide a forum for work and discussion.
Best,
WG Component Standard Chairs @mtaufen, @stealthybox, @sttts