Re: Proposal to adopt Krew as a SIG CLI subproject

[Ahmet Alp Balkan]

Trying +kubernetes-sig-architecture again as it bounced the first time.

On Tue, Mar 5, 2019 at 12:51 PM Ahmet Alp Balkan <ahm...@google.com> wrote:

Hello SIG CLI/Architecture/Apps,

In last week's SIG CLI meeting, I've made a request for SIG CLI to adopt the

Krew project (the kubectl plugin manager) as a subproject.

If you're not familiar, Krew is developed at Google for installing and

distributing kubectl plugins. For kubectl users: they can discover plugins,

install them with a single command, and keep them up-to-date. For plugin

developers: they can easily package their plugins for multiple OSes and make

them discoverable on Krew. (This article has more details on why we developed

Krew.)

Even though the kubectl plugin ecosystem is still in an infancy period, Krew has

already become the de facto tool for distributing plugins. It currently hosts

over 30 kubectl plugins in its centralized index.

We are seeing a good uptick in the number of plugins developed lately.

Therefore, it would be better for Krew project to be owned the Kubernetes

community going forward. The community can better decide what's good for the

plugin ecosystem. For example, what are the acceptance criteria to the

centralized plugin index, what are acceptable plugin names, or, what’s the

security/trust story around plugins we distribute are stuff we need to go figure

out. (Here are more details on such governance challenges.)

Therefore, I propose we move the Krew project to kubernetes-sigs org, maintain

it with community participation and decide its future in a vendor-neutral way.

What are your thoughts?

-Ahmet Alp Balkan

[Daniel Smith]

I think SIG CLI is probably the best place to discuss; I wouldn't expect SIG Architecture to be in the decision path for this.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cli" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.
To post to this group, send email to kubernete...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cli/CAEBbUmYPohyWmE_LJq5krgD_6ZCupHmNHXCZ3DoDGHBE3mKW-w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Brendan Burns]

Without passing judgement on krew one way or the other, I'd like to ask the meta-question of "do we believe everything should be a SIG project"

SIG projects were intended to be something that a SIG created, not something that someone wanted to find a home in the kubernetes project.

Indeed we explicitly wanted to avoid the notion that people placed things in kubernetes projects for "endorsement"

Krew seems perfectly great as an ecosystem project, I don't see a lot of value in projects being owned by a SIG unless most of that SIG is planning on working on the project. (e.g. it is created by the SIG, rather than vis versa)

--brendan

---

From: 'Daniel Smith' via kubernetes-sig-architecture <kubernetes-si...@googlegroups.com>
Sent: Tuesday, March 5, 2019 12:57 PM
To: Ahmet Alp Balkan
Cc: kubernetes-sig-architecture; kubernetes-sig-apps; kubernetes-sig-cli
Subject: Re: Proposal to adopt Krew as a SIG CLI subproject

 

You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.
To post to this group, send email to kubernetes-si...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAB_J3ba1OmYdWMO_12b4bsw-mFqw4cFXBBqQ0VJMmeh6Y_kgcA%40mail.gmail.com.

[Daniel Smith]

If this is for endorsement, I agree with Brendan; if it's because SIG CLI needs a solution for the problem and wants to adopt krew, then it sounds fine (better to multiply subprojects than sigs, anyway!).

But either way, I think SIG CLI should make the call.

[Brendan Burns]

yep, 100% agree w/ everything Daniel said 🙂

---

From: Daniel Smith <dbs...@google.com>
Sent: Tuesday, March 5, 2019 1:23 PM
To: Brendan Burns
Cc: Ahmet Alp Balkan; kubernetes-sig-architecture; kubernetes-sig-apps; kubernetes-sig-cli

[Matt Farina]

+1 to SIG CLI making the call

I generally tend to suggest things be ecosystem projects at this point unless there is a good reason not to. It's a way to scale people things where many things can have a loose process. But, this snippet convinced me that a vendor neutral location would be a good idea:

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CY4PR21MB05043CE6C160A80BE84E6A46DB720%40CY4PR21MB0504.namprd21.prod.outlook.com.

For more options, visit https://groups.google.com/d/optout.

--

Matt Farina

mattfarina.com

Go in Practice - A book of Recipes for the Go programming language.

Code Engineered - A blog on cloud, web, and software development.

[Brian Grant]

SIG CLI should definitely decide.

It sounds like developing the plugin criteria, process, and infrastructure would require significant work, as would ongoing curation. 

AIUI, Helm moved away from a centralized community chart repo in order to federate the curation effort.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cli/CAMPAG2puX8cPkKZkVXmA48dgW2HzSVRc6Aw94_R58XmqNVh4_Q%40mail.gmail.com.