Author here. This was an extremely hard topic to write about. Happy to answer questions but really hoping those from sig-cli and sig-architecture chime in here. Is this Kerfuffle the root of the sudden resurgence of KEPs?
Non-native reader/kubernetes learner here. I know only keywords from this article. It's a pity that I cannot get the full meaning of it, but still it provide a chance for me to learn some upstream news.
Hi! If you're up for it, I'd love to do a recorded video/voice call to listen to your feedback and perhaps even try to fill in the topic areas that non-obvious to learners. Talking to folks about 'nettes is the highlight of my day. Send a note to the email in my profile?
I'd like you to start a series on less-formal activities surrounding the k8s community. For example, public events, new major adopters, war story of using k8s that affect k8s' fundamental technical philosophy, etc.
One thing comes to mind is to describe how k8s has evolved in a certain time frame, and some of interesting changes of courses (if any) and important events, controversies, etc.
This is very difficult to write though, needs to go through a huge pile of history. Just my selfindulged request.
Indeed, someone in a separate channel explained that new sig-pm staffing is at the root of the resurgence of KEPs. Thanks justinsb, no relation to GCP's Justin Santa Barbara?
Other way around. Hi I'm the Kubernetes 1.14 release lead, I work for Google, and I'm the guy who said "bumpy road"
During the Kubernetes Contributor Summit at KubeCon Seattle last year, I made lots of noise about using KEPs, and about needing non-technical contributors to help those of us who are "organizationally challenged". In what I hope was a response, people showed up at SIG PM.
I think this conversation was really kicked back up in earnest as a result of Windows node support not landing in 1.13 due to a lack of clarity on what the bar was for release. There were other enhancements that could have had a smoother landings in this and previous releases, but this was definitely when we realized we needed to overhaul and document this part of the project.
Question: one of the main advantages of helm (for me) is the pruning of dead resources.
As in, my chart contains 3 services , I remove one of them including some related things like secrets, configmaps, etc and deploy, helm will clean up everything redundant.
It does not. Kustomize only generates the manifests. Typically you'd use a GitOps-driven CD application (ArgoCD, Weave Flux) to create/change/delete resources.
Correction for your post, it's a CNCF Technical Oversight Committee (TOC) rather than a Kubernetes one. The Kubernetes steering committee oversees Kubernetes. The CNCF TOC oversees all the CNCF projects (Prometheus, Kubernetes, Helm, etc).
