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 <flyrain...@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 <yzh...@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 > > > > > > > > > > > > > > >
