11–20 of 51 posts
Earlier quoted context omitted.
Not the cause. The release team asked for KEPs for all new features in the next release and the deadline was today.
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?
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?
Kustomize is definitely a huge step forward for configuration management, more info on Kustomize here: www.kustomize.io
kustomize vs Helm is a bit if an improper comparison. Kustomize and the ways to use kubectl are often about configuration management and Helm is about package management. This is an important difference.
For example, take Ansible doing configuration management and using Helm to install a package in much the same way you might use an apt package elsewhere.
The key question that has to do with configuration management is should kubectl provide configuration management of things outside of the Kubernetes API, such as when you manage the config in git? This is both about scope (is this a Kubernetes concern) and in how to build things (a monolithic CLI?).
If kubectl has a configuration management opinion outside of the Kubernetes API what does that mean for configuration management projects like ansible, armada, chef, and the oh so many others? And, who working on Kubernetes gets to choose the opinion on configuration management it has outside the API?
At this point imperative vs declarative as a conversation point comes up. In all cases the configuration is declared to the Kubernetes API and stored by Kubernetes in a declarative manner. It becomes a question of how far outside the Kubernetes API do things need to remain declarative. After all, me typing into yaml into a keyboard is imperative.
As for the KEP process as a whole and the graduation criteria that was mentioned here, we know it needs work. There are efforts going to get it into better shape with better example guidance. There is actually a PR being worked on for this right now.
Projects with a healthy ecosystem and people of strong opinions have to deal with issues of scope. What do you hold onto and where should it go? How do you curate a healthy ecosystem? It's not always easy.
Having a place to do some experiments outside of a project like Kubernetes is part of the reason the CNCF added sandbox projects. Without being forceful people can work together on something and see how it fairs in the market. Experiments in the ecosystem can happen.
In any case, if people have questions please feel free to ask.
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?
I've been on both sides of this sort of divide, as both insider and outsider. It's easy to see it as politics. I do, pretty much all the time, but that's because I have a background in politics. I'm primed to assume the worst. I think the explanation is simpler. If you are a Googler, you mostly talk to Googlers, you mostly come to quick consensus that way, and it all makes sense to you and the Googlers you had casual…
You missed the key part. This is why it was open sourced, as a balance between control leverage and adoption.
I feel like I read this kind of statement all the time and I don't understand the reasoning behind it.
Google came up with k8s. They could have kept it for themselves, or, open source it. They open-sourced it. It definitely benefits them, but, it also benefits us a lot.
Saying they "open sourced, as a balance between control leverage and adoption" is so cynical. So I'd like to ask, what's the alternative? Not open-sourcing? Who would that benefit?
What would be the non-ill-intentioned alternative that Google supposedly could have chosen?
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?
Your writing style is hilarious, bordering on poetic. It is somewhat hard to follow the actual information though, and non-native speakers will probably struggle quite a bit.
Thanks for speaking out for us!
Earlier quoted context omitted.
You missed the key part. This is why it was open sourced, as a balance between control leverage and adoption.
> This is why it was open sourced, as a balance between control leverage and adoption. I feel like I read this kind of statement all the time and I don't understand the reasoning behind it. Google came up with k8s. They could have kept it for themselves, or, open source it. They open-sourced it. It definitely benefits them, but, it also benefits us a lot. Saying they "open sourced, as a balance between control levera…