You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@polaris.apache.org by Yong Zheng <yz...@apache.org> on 2025/07/06 00:21:49 UTC

Remove k8s reference for kind

Hello,

Currently, we provide Kubernetes references for both Kind (https://kind.sigs.k8s.io/) and Minikube (https://minikube.sigs.k8s.io/docs/). In terms of tooling, Kind is very lightweight, whereas Minikube is much more feature-rich and works out of the box. (Some workarounds or additional steps are required to make Kind do the same, but those details are out of scope for this discussion.)

In terms of the features and documentation we offer to others, either option will work. However, I think the overhead of maintaining support for both tools is unnecessary. I don’t have a strong preference for which one we choose, but I believe it will be easier to support additional automation if we stick to a single tool.

Thanks,
Yong Zheng

Re: Remove k8s reference for kind

Posted by ybo1003 <yb...@gmail.com>.

Thanks
---- Replied Message ----
FromYong Zheng<yz...@apache.org>Date7/6/2025 08:22To<de...@polaris.apache.org>SubjectRemove k8s reference for kind
Hello,
Currently, we provide Kubernetes references for both Kind (https://kind.sigs.k8s.io/) and Minikube (https://minikube.sigs.k8s.io/docs/). In terms of tooling, Kind is very lightweight, whereas Minikube is much more feature-rich and works out of the box. (Some workarounds or additional steps are required to make Kind do the same, but those details are out of scope for this discussion.)
In terms of the features and documentation we offer to others, either option will work. However, I think the overhead of maintaining support for both tools is unnecessary. I don’t have a strong preference for which one we choose, but I believe it will be easier to support additional automation if we stick to a single tool.
Thanks,
Yong Zheng

Re: Remove k8s reference for kind

Posted by Yong Zheng <yz...@apache.org>.

PR: https://github.com/apache/polaris/pull/2028

On 2025/07/11 05:26:20 Yong Zheng wrote:
> Great. I think everyone likes minikube in this case. I will raise a PR for removing kind. Thanks for the input.
> 
> Thanks,
> Yong
> 
> On 2025/07/08 09:47:44 Alex Dutra wrote:
> > Hi,
> > 
> > I also have a preference for minikube – even if Kind has the ability of
> > launching multi-node clusters, which minikube can't do.
> > 
> > Historically, Kind was used in one single place: the run.sh script at the
> > root of the repo. I think it was chosen so that we can launch a local
> > Docker registry (cf. the companion kind-registry.sh script) to upload
> > Docker images for Polaris. But minikube has a much easier way of achieving
> > that [1], so my take is that we don't need Kind at all at this point.
> > 
> > Thanks,
> > Alex
> > 
> > [1]:
> > https://minikube.sigs.k8s.io/docs/handbook/pushing/#1-pushing-directly-to-the-in-cluster-docker-daemon-docker-env
> > 
> > On Mon, Jul 7, 2025 at 11:57 PM Yufei Gu <fl...@gmail.com> wrote:
> > 
> > > +1 on picking one, instead of having both. I don't have any preference
> > > though.
> > >
> > > Yufei
> > >
> > >
> > > On Mon, Jul 7, 2025 at 1:37 PM Dmitri Bourlatchkov <di...@apache.org>
> > > wrote:
> > >
> > > > My personal preference is minikube.
> > > >
> > > > Cheers,
> > > > Dmitri.
> > > >
> > > > On Sat, Jul 5, 2025 at 8:22 PM Yong Zheng <yz...@apache.org> wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > Currently, we provide Kubernetes references for both Kind (
> > > > > https://kind.sigs.k8s.io/) and Minikube (
> > > > > https://minikube.sigs.k8s.io/docs/). In terms of tooling, Kind is very
> > > > > lightweight, whereas Minikube is much more feature-rich and works out
> > > of
> > > > > the box. (Some workarounds or additional steps are required to make
> > > Kind
> > > > do
> > > > > the same, but those details are out of scope for this discussion.)
> > > > >
> > > > > In terms of the features and documentation we offer to others, either
> > > > > option will work. However, I think the overhead of maintaining support
> > > > for
> > > > > both tools is unnecessary. I don’t have a strong preference for which
> > > one
> > > > > we choose, but I believe it will be easier to support additional
> > > > automation
> > > > > if we stick to a single tool.
> > > > >
> > > > > Thanks,
> > > > > Yong Zheng
> > > > >
> > > >
> > >
> > 
>

Re: Remove k8s reference for kind

Posted by Yong Zheng <yz...@apache.org>.

Great. I think everyone likes minikube in this case. I will raise a PR for removing kind. Thanks for the input.

Thanks,
Yong

On 2025/07/08 09:47:44 Alex Dutra wrote:
> Hi,
> 
> I also have a preference for minikube – even if Kind has the ability of
> launching multi-node clusters, which minikube can't do.
> 
> Historically, Kind was used in one single place: the run.sh script at the
> root of the repo. I think it was chosen so that we can launch a local
> Docker registry (cf. the companion kind-registry.sh script) to upload
> Docker images for Polaris. But minikube has a much easier way of achieving
> that [1], so my take is that we don't need Kind at all at this point.
> 
> Thanks,
> Alex
> 
> [1]:
> https://minikube.sigs.k8s.io/docs/handbook/pushing/#1-pushing-directly-to-the-in-cluster-docker-daemon-docker-env
> 
> On Mon, Jul 7, 2025 at 11:57 PM Yufei Gu <fl...@gmail.com> wrote:
> 
> > +1 on picking one, instead of having both. I don't have any preference
> > though.
> >
> > Yufei
> >
> >
> > On Mon, Jul 7, 2025 at 1:37 PM Dmitri Bourlatchkov <di...@apache.org>
> > wrote:
> >
> > > My personal preference is minikube.
> > >
> > > Cheers,
> > > Dmitri.
> > >
> > > On Sat, Jul 5, 2025 at 8:22 PM Yong Zheng <yz...@apache.org> wrote:
> > >
> > > > Hello,
> > > >
> > > > Currently, we provide Kubernetes references for both Kind (
> > > > https://kind.sigs.k8s.io/) and Minikube (
> > > > https://minikube.sigs.k8s.io/docs/). In terms of tooling, Kind is very
> > > > lightweight, whereas Minikube is much more feature-rich and works out
> > of
> > > > the box. (Some workarounds or additional steps are required to make
> > Kind
> > > do
> > > > the same, but those details are out of scope for this discussion.)
> > > >
> > > > In terms of the features and documentation we offer to others, either
> > > > option will work. However, I think the overhead of maintaining support
> > > for
> > > > both tools is unnecessary. I don’t have a strong preference for which
> > one
> > > > we choose, but I believe it will be easier to support additional
> > > automation
> > > > if we stick to a single tool.
> > > >
> > > > Thanks,
> > > > Yong Zheng
> > > >
> > >
> >
>

Re: Remove k8s reference for kind

Posted by Alex Dutra <al...@dremio.com.INVALID>.

Hi,

I also have a preference for minikube – even if Kind has the ability of
launching multi-node clusters, which minikube can't do.

Historically, Kind was used in one single place: the run.sh script at the
root of the repo. I think it was chosen so that we can launch a local
Docker registry (cf. the companion kind-registry.sh script) to upload
Docker images for Polaris. But minikube has a much easier way of achieving
that [1], so my take is that we don't need Kind at all at this point.

Thanks,
Alex

[1]:
https://minikube.sigs.k8s.io/docs/handbook/pushing/#1-pushing-directly-to-the-in-cluster-docker-daemon-docker-env

On Mon, Jul 7, 2025 at 11:57 PM Yufei Gu <fl...@gmail.com> wrote:

> +1 on picking one, instead of having both. I don't have any preference
> though.
>
> Yufei
>
>
> On Mon, Jul 7, 2025 at 1:37 PM Dmitri Bourlatchkov <di...@apache.org>
> wrote:
>
> > My personal preference is minikube.
> >
> > Cheers,
> > Dmitri.
> >
> > On Sat, Jul 5, 2025 at 8:22 PM Yong Zheng <yz...@apache.org> wrote:
> >
> > > Hello,
> > >
> > > Currently, we provide Kubernetes references for both Kind (
> > > https://kind.sigs.k8s.io/) and Minikube (
> > > https://minikube.sigs.k8s.io/docs/). In terms of tooling, Kind is very
> > > lightweight, whereas Minikube is much more feature-rich and works out
> of
> > > the box. (Some workarounds or additional steps are required to make
> Kind
> > do
> > > the same, but those details are out of scope for this discussion.)
> > >
> > > In terms of the features and documentation we offer to others, either
> > > option will work. However, I think the overhead of maintaining support
> > for
> > > both tools is unnecessary. I don’t have a strong preference for which
> one
> > > we choose, but I believe it will be easier to support additional
> > automation
> > > if we stick to a single tool.
> > >
> > > Thanks,
> > > Yong Zheng
> > >
> >
>

Re: Remove k8s reference for kind

Posted by Yufei Gu <fl...@gmail.com>.

+1 on picking one, instead of having both. I don't have any preference
though.

Yufei


On Mon, Jul 7, 2025 at 1:37 PM Dmitri Bourlatchkov <di...@apache.org> wrote:

> My personal preference is minikube.
>
> Cheers,
> Dmitri.
>
> On Sat, Jul 5, 2025 at 8:22 PM Yong Zheng <yz...@apache.org> wrote:
>
> > Hello,
> >
> > Currently, we provide Kubernetes references for both Kind (
> > https://kind.sigs.k8s.io/) and Minikube (
> > https://minikube.sigs.k8s.io/docs/). In terms of tooling, Kind is very
> > lightweight, whereas Minikube is much more feature-rich and works out of
> > the box. (Some workarounds or additional steps are required to make Kind
> do
> > the same, but those details are out of scope for this discussion.)
> >
> > In terms of the features and documentation we offer to others, either
> > option will work. However, I think the overhead of maintaining support
> for
> > both tools is unnecessary. I don’t have a strong preference for which one
> > we choose, but I believe it will be easier to support additional
> automation
> > if we stick to a single tool.
> >
> > Thanks,
> > Yong Zheng
> >
>

Re: Remove k8s reference for kind

Posted by Dmitri Bourlatchkov <di...@apache.org>.

My personal preference is minikube.

Cheers,
Dmitri.

On Sat, Jul 5, 2025 at 8:22 PM Yong Zheng <yz...@apache.org> wrote:

> Hello,
>
> Currently, we provide Kubernetes references for both Kind (
> https://kind.sigs.k8s.io/) and Minikube (
> https://minikube.sigs.k8s.io/docs/). In terms of tooling, Kind is very
> lightweight, whereas Minikube is much more feature-rich and works out of
> the box. (Some workarounds or additional steps are required to make Kind do
> the same, but those details are out of scope for this discussion.)
>
> In terms of the features and documentation we offer to others, either
> option will work. However, I think the overhead of maintaining support for
> both tools is unnecessary. I don’t have a strong preference for which one
> we choose, but I believe it will be easier to support additional automation
> if we stick to a single tool.
>
> Thanks,
> Yong Zheng
>