Rethink "kind" project name

[remram44]

What would you like to be added:
A different, unique name for this project, that is searchable.

Why is this needed:
"kind" is a very common word used everywhere in the Kubernetes ecosystem. Every manifest or object contains a "kind" field. I am not even able to figure out if this issue is a duplicate, because searching the bug tracker for "kind name" brings up almost a thousand issues, which is the point. I am sorry to bring up such an obvious point but I think it deserves to be discussed.

I see that you have a roadmap to 1.0. I strongly urge you to reconsider the naming of this tool. Especially as a lot of the ecosystem is no longer centered on Docker, with tools like podman, it might be a good time to pick a searchable name.

To get the ball rolling, and though I really don't care what the name is so long as it's unique, how about:

• kubend (Kubernetes 'n docker)
• kubedocker, kubedock
• kubecontain
• k8box / kbox
• kubebox / kubox (kübox exists but might be different enough?)
• instakube

Again I am sorry if this is a duplicate but I hope you will consider this. Even files that are not Kubernetes API objects are starting to use the convention, for example Kyverno CLI ("apiVersion": "cli.kyverno.io/v1alpha1", "kind": "Test"), Tilt ("apiVersion": "tilt.dev/v1alpha1", "kind": "Cluster"), kind's own config file ("kind": "Cluster", "apiVersion": "kind.x-k8s.io/v1alpha4"). Even searchers like "kind cluster" will soon stop being specific enough...

[aojea]

#1321

[remram44]

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.

[aojea]

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,

[aojea]

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.

[remram44]

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?

[aojea]

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 :)

[remram44]

I'm talking about developing apps that run on Kubernetes

[aojea]

I'm talking about developing apps that run on Kubernetes

absolutely recommended

[BenTheElder]

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

[remram44]

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.

[BenTheElder]

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.