I'd like to express my support for this SIG. Myself and a few others in the community have recently talked about arranging a meeting at KubeCon EU to discuss best practices around controller design (in the end, I've submitted a request for some time during the developer summit day). I think there's a growing demand for this kind of formality around controller design, especially as more and more people are beginning to design controllers in order to provide 'value add' in Kubernetes.
I assume the "potential subprojects" would include projects that make it easier/formalise practices around building extensions, as opposed to encompassing these projects themselves? I'd be really keen to get involved with the SIG, and if there's any way that I can help, please let me know! :) James On Monday, 2 April 2018 23:22:33 UTC+1, Jimmy Zelinskie wrote: > Mission Statement > A Special Interest Group focused on toolkits for developers who extend the > Kubernetes platform by writing command line tools and API extensions such as > operators. > > Proposed Name > SIG-Platform-Dev, indicating that the SIG supports developers who extend the > Kubernetes platform. > > Secondary Statement > This SIG will focus on the tooling used to build, run, upgrade, and maintain > API extensions to Kubernetes and will drive direct feedback on the core > primitives used for extension that are maintained by SIG API Machinery. > > Purpose > Most developers are familiar with the term “operators”, but this concept has > yet to have organization and consensus in upstream development of Kubernetes. > There now exists a fractured ecosystem of Kubernetes feature extensions, > especially as productized distributions of Kubernetes continue to > differentiate from upstream. Similarly, there are many distinct but > overlapping tools and resources aimed at helping people create such > extensions. This SIG will serve as the centralized point for discussion and > development of subprojects in order to better understand users’ intentions to > extend Kubernetes and collaborate on a cohesive set of tools to help them do > so. > > Relation to Existing SIGs > SIG-Apps will continue to own generic (apps/v1) controllers. SIG-Apps will > continue to be the first place that K8s users go to discuss running > applications on Kubernetes. Discussion of use of generic (apps/v1) > controllers and the operator pattern would continue to occur in SIG-Apps. > Deeper discussion of operator development tools, such as SDKs, would happen > in this SIG. Apps and this SIG would jointly work on how operator > generation tools will embody best practices for running Apps on Kubernetes. > SIG-API Machinery would continue to own the code in API server. API Machinery > and this SIG would collaborate on changes to the API extension APIs (e.g. > apiextension API group). Responsibility for code generation and client > generation initially remains part of API machinery, but might transition to > this SIG with the advice and consent of API Machinery. > SIG-CLI would continue to own code in kubectl. Members of this SIG would > likely contribute changes and test code to kubectl to ensure support for > CRDs, and for other artifacts generated by this SIG's tooling. > The proposed Developer Tools Working Group would have application developers > as an audience (people who write services that run on K8s). This is quite a > different audience than "platform developers" who write extensions to > Kubernetes. So, minimal overlap here. > > Potential Subprojects > github.com/kubernetes-sigs/kubebuilder > github.com/GoogleCloudPlatform/metacontroller > > Implementation > The SIG will meet via Zoom bi-weekly for demos, scheduled discussions, and > product planning. > First meeting will be a face to face meeting at KubeCon EU. > > Potential Initial Chairs > Jimmy Zelinskie (Red Hat) > Phillip Wittrock (Google) > Anthony Yeh (Google) -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
