Rethink "kind" project name about kind HOT 11 CLOSED

I am sorry to bring up such an obvious point but I think it deserves to be discussed.

Very disappointing to see so little concern for end users.

I don't know if is me but it seems the tone you are using in your comments is a bit condescending,

from kind.

#1321

from kind.

The arguments there seem to be:

• Renaming all the internal package names would take a lot of effort (true, but you really don't have to do it!)
• This project is still the first result if you search for "kubernetes kind" on Google
  • that's really not the point, users are going to search for answers to specific problems, that is when the "kind" keyword hurts
  • users are going to search kind in other avenues, for example GitHub issues, GitHub code, etc where it is already terrible (Google can prioritize headings, page titles, etc which helps finding articles specifically about kind, but that doesn't help here)

Very disappointing to see so little concern for end users.

from kind.

To be clear @remram44 , and focusing on the message, I agree with your point and I think that most of the people does, the conclusion described here #1321 (comment) seems to be pretty accurate, and this is a project meant to serve Kubernetes CI specifically, a change like that has a lot of consequences as a lot of CI in the world may be broken, the development of kubernetes itself will be impacted. It is maintained by @BenTheElder and I in our spare time, so is hard to do such time consuming change, despite we know is far from the best solution. We try to do our best for our users and we are very glad of the feedback, but as you may know in OSS not always is possible or feasible to do certain things.

from kind.

Your website says (first sentence):

may be used for local development

It has definitely been an invaluable tool to develop Kubernetes apps for me, not just Kubernetes itself. I know many others who do so too. Is such use officially unsupported, and you recommend using e.g. Minikube?

from kind.

It has definitely been an invaluable tool to develop Kubernetes apps for me, not just Kubernetes itself. I know many others who do so too. Is such use officially unsupported, and you recommend using e.g. Minikube?

on the contrary, the official use case is to develop kubernetes, that is the main goal, KIND gates kubernetes code on presubmits, if kind does not work the project is blocked.
As a consequence is the ideal tool for development as it is always in sync with kubernetes codebase itself :)

from kind.

I'm talking about developing apps that run on Kubernetes

from kind.

I'm talking about developing apps that run on Kubernetes

absolutely recommended

from kind.

Yes, See P1: https://kind.sigs.k8s.io/docs/contributing/project-scope/

from kind.

Forgive me if I misunderstand, but I see the statement that "this is a project meant to serve Kubernetes CI specifically" and having the "developing apps that run on Kubernetes" be "recommended" are completely opposite viewpoints.

Either you are focusing on internal use to develop the Kubernetes platform itself, by Kubernetes developers, in which case ignoring changes that only benefit application developers/Kubernetes end-users makes total sense. Or you want to support/recommend wider usage by application developers in which case, although you might not have time to address it by yourself or soon, you might want to consider usability problems as open issues.

It's a little puzzling to me that you would brush usability issues aside because it's meant to be an internal tool while still recommending it for external use. Especially when another kubernetes-sig tool, minikube, opens up on their website with "We proudly focus on helping application developers" already.

from kind.

Forgive me if I misunderstand, but I see the statement that "this is a project meant to serve Kubernetes CI specifically" [...]

This is how the project started and it remains the top priority, as clearly documented.

and having the "developing apps that run on Kubernetes" be "recommended" are completely opposite viewpoints.

It's not opposing. See the page linked above, our first priority is testing Kubernetes, our second priority is developing applications and so on. The project has many use-cases, multiple of which are explicitly supported. Some others are covered by external extensions like https://github.com/kubernetes/kubeadm/tree/main/kinder, https://github.com/kubernetes-sigs/cluster-api/blob/main/test/infrastructure/docker/README.md, or even minikube, which reuses images/base and we regularly collaborate.

Either you are focusing on internal use to develop the Kubernetes platform itself, by Kubernetes developers, in which case ignoring changes that only benefit application developers/Kubernetes end-users makes total sense. Or you want to support/recommend wider usage by application developers in which case, although you might not have time to address it by yourself or soon, you might want to consider usability problems as open issues.

This is a false dichotomy.

It's a little puzzling to me that you would brush usability issues aside because it's meant to be an internal tool while still recommending it for external use. Especially when another kubernetes-sig tool, minikube, opens up on their website with "We proudly focus on helping application developers" already.

We are not "ignoring changes that only benefit application developers/Kubernetes end-users", there have been plenty of those and we spend plenty of time on these.

We are not however renaming the tool, we've been over this already and there's a wealth of materials and references to it.
Bad name or not, it's the name, it's widely known, and the non-trivial churn to rebrand is not worth it.

I think you are "brushing aside" the effort involved in rebranding.

As for issues on this topic, if you search "rename kind" in the issue tracker the past issues that will turn up in a relatively short list.

There is overlap with many local cluster tools, with different trade-offs as a user, I recommend trying them out and seeing which work best for you.

from kind.