3 ms·

Hi mfer! Writer here, wonderful to virtually meet you. I applaud your unique gusto and framing of questions. (btw, pretty much every question/quote was from you

Hi mfer! Writer here, wonderful to virtually meet you. I applaud your unique gusto and framing of questions. (btw, pretty much every question/quote was from you) From afar it looks like `kubectl -k` is due to land despite the expressed concerns. What was your response to sig-arch and sig-cli leads who mentioned that the kustomize features were always intended to be there? I may have missed that, if it was public. Do you expect that the march toward kustomize inclusion will change after the kubectl usage data has been collected and analyzed? And what are you setting your sights on next? May I write about it? :)

mfer 8y ago
> What was your response to sig-arch and sig-cli leads who mentioned that the kustomize features were always intended to be there? I may have missed that, if it was public. The document describing what kustomize should do and that looked at some other tools was started in mid-2017. Do you have tracability to the idea that overlays were meant to be there from the beginning? I ask because I'm honestly interested in reading that. As far as people go, 1 of the 3 SIG Arch chairs has been around a long time. In addition to him I would want to poke at the co-founders on this one. Joe Beda and Craig McLuckie (2/3 of the K8s cofounders) started Heptio and they produced ksonnet (kubernetes + jsonnet which both came out of Google). This is different than the direction for kustomize. Kubernetes has been declarative from the beginning. It's an important concept in all of this. Isn't declaring it to the API and then storing/creating objects outside the API separate concerns? Back in 2017 Helm was a core part of Kubernetes as were projects like Komponse, that lets you convert Docker Compose files into Kubernetes manifests. Helm v2, which was part of Kubernetes, was the product of merging deployment manager, a Kubernetes project out of Google, and Helm v1, by Deis. Helm v2 began work before the CNCF existed. It was a part of Kubernetes back when it was governed by Google. A history of tooling outside of the API had long been there. To not have opinions outside the API to allow more diversity there, in 2017 we started treating Helm and Kompose like other ecosystem projects. We talked about not adding opinionated projects like this within Kubernetes anymore to keep the door open for the ecosystem and diversity there. > Do you expect that the march toward kustomize inclusion will change after the kubectl usage data has been collected and analyzed? I think it depends where the usage data comes from. Can we get real end user data? Or, will the feedback come from the Kubernetes insiders as has happened too often in the surveys? (I ran past surveys so I feel this pain) What will the data look like from large companies with bespoke processes and strong opinions on their toolchains? I hope real useful data is collected? I would love data on more of the problem their facing.

mfer 8y ago

> What was your response to sig-arch and sig-cli leads who mentioned that the kustomize features were always intended to be there? I may have missed that, if it was public. The document describing what kustomize should do and that looked at some other tools was started in mid-2017. Do you have tracability to the idea that overlays were meant to be there from the beginning? I ask because I'm honestly interested in reading that. As far as people go, 1 of the 3 SIG Arch chairs has been around a long time. In addition to him I would want to poke at the co-founders on this one. Joe Beda and Craig McLuckie (2/3 of the K8s cofounders) started Heptio and they produced ksonnet (kubernetes + jsonnet which both came out of Google). This is different than the direction for kustomize. Kubernetes has been declarative from the beginning. It's an important concept in all of this. Isn't declaring it to the API and then storing/creating objects outside the API separate concerns? Back in 2017 Helm was a core part of Kubernetes as were projects like Komponse, that lets you convert Docker Compose files into Kubernetes manifests. Helm v2, which was part of Kubernetes, was the product of merging deployment manager, a Kubernetes project out of Google, and Helm v1, by Deis. Helm v2 began work before the CNCF existed. It was a part of Kubernetes back when it was governed by Google. A history of tooling outside of the API had long been there. To not have opinions outside the API to allow more diversity there, in 2017 we started treating Helm and Kompose like other ecosystem projects. We talked about not adding opinionated projects like this within Kubernetes anymore to keep the door open for the ecosystem and diversity there. > Do you expect that the march toward kustomize inclusion will change after the kubectl usage data has been collected and analyzed? I think it depends where the usage data comes from. Can we get real end user data? Or, will the feedback come from the Kubernetes insiders as has happened too often in the surveys? (I ran past surveys so I feel this pain) What will the data look like from large companies with bespoke processes and strong opinions on their toolchains? I hope real useful data is collected? I would love data on more of the problem their facing.