kubespray/kargo incubation proposal

[Antoine Legrand]

Hi, 

I forward the discussion about Kargo incubation proposal in this sig. 

Original discussion: https://groups.google.com/forum/#!topic/kubernetes-dev/3kQW9VNjkdg

For a year now, we tried to make kubernetes deployment in production easy for everyone and everywhere. Kargo has today good number of users and it's in active development with various contributors / companies involve. 

 

There are many different infrastructure constraints or opinion about what are the best configurations/tools to deploy with kubernetes. One of Kargo's goals is to be the least possible opinionated and let the users make the important choices (network/cloud/baremetal/os/container-engine...). 

 Many other tools are either focusing on a single facet (e.g aws-only, any-cloud+weave, baremetal+flanel...), or deploy dev/demo clusters only. 

  

Kargo is already used as the production deployment tool in several companies. 

We would like to incubate it and continue our work to bring a tool that fit any/many production infrastructure and to work more closely with upstream/kubeadm direction. 

Kargo repo: https://github.com/kubespray/kargo

Incubation proposal: https://docs.google.com/document/d/1AdzNm3jz_m61zZsiSU5G-1-WJLv_4sAa7BFBrKdhPuY

How can we progress on this request? 

Thanks,

Antoine Legrand 

 
On Monday, October 17, 2016 at 4:37:39 PM UTC+2, Tim Hockin wrote:

Cluster-lifecycle

On Oct 17, 2016 7:09 AM, "Eric Paris" <epa...@redhat.com> wrote:

As the original author of kubernetes ansible I also support this
request. But, I do not know what 'SIG' it should participate with. When
we move kargo into into incubation I will start pointing users of the
contrib ansible to kargo. contrib ansible, while it works, is largely
on life support. A couple of us fix things that come along, but as new
deployment tools, new configuration mechanisms, etc are developed by
others in the community we are not engaged to enable those tools.

We would rather join with the kargo people than have 2 similar
competing efforts.

-Eric


On Fri, 2016-10-14 at 19:24 +0300, Matthew Mosesohn wrote:
> Dear Kubernetes community members:
>
>
> In August[0], fellow contributor Smaine Kahlouch started an
> incubation
> proposal request to bring Kargo into the Kubernetes Incubator. It
> seems that there is a requirement for a SIG to sponsor any new
> incubation project. We thought that the clear choice for supporting
> an
> Ansible-based configuration management tool for Kubernetes would be
> sig-cluster-lifecycle or sig-cluster-ops.
>
> Given the evidence that sig-cluster-lifecycle acts principally as a
> workshop for developing kubeadm, I don’t think that the
> cluster-lifecycle SIG is the right place to appeal for an incubation
> request. I’d like to ask the general Kubernetes community who can
> point us to an appropriate SIG that would take an interest in
> endorsing the development of a flexible Kubernetes deployment system
> geared toward production readiness?
>
> For those not already familiar with Kargo, I would like to share a
> bit
> about our project and its key features. Kargo deploys Kubernetes with
> flexibility in node role distribution, support for popular network
> plugins (Weave, Calico, Flannel), supports upgrades, several popular
> operating systems, deploying in an all-containerized manner. Kargo
> offers an HA apiserver through a localhost nginx reverse proxy
> (workaround for [1]).
>
> For many deployers, an idempotent tool plays a huge role in
> validating
> deployments and uniformity. As it goes, Ansible serves as one of the
> major configuration management tools du jour. The contrib/ansible
> project has largely gone by the wayside without much attention in the
> last several months. The Kubernetes community should definitely
> consider embracing ancillary projects that deploy Kubernetes through
> traditional configuration management because they do the tasks that
> golang itself isn’t suited for.
>
>
> I would also like to address some of the concerns you might have with
> our incubation request.
>
> Why aren’t we simply contributing to kubeadm?
>
> Kubeadm is a tool that creates a master and joins minion Kubernetes
> nodes. It does not handle package management of Docker and Kubernetes
> core components. While it still lacks upgrades and HA, those are
> definitely areas that really deserve attention. I have every
> intention
> of implementing kubeadm in Kargo if and when it becomes “production
> ready”. Additionally, my colleagues and I are looking at where we can
> make effective contributions there already.
>
> What about kubernetes/contrib/ansible?
>
> The entire contrib project was excluded from incubation. If they were
> automatically included, we would have merged efforts with that team.
> I’ve already had several conversations with those developers and
> discovered that it is not very actively maintained. I highly
> anticipate we will consolidate those efforts and feature sets if and
> when Kargo reaches incubation.
>
> We already have lots of deployment tools in kubernetes GitHub space.
> Why is Kargo different?
>
> There are several repositories with deployment tools located in
> github.com/kubernetes space, including in kube-deploy, kops, and
> contrib. None of these are incubated and most come from a single
> vendor. Kargo has a considerably more diverse contributor base and a
> strong roadmap[2].
>
>
> [0] https://groups.google.com/forum/?utm_medium=email&utm_source=foot
> er#!msg/kubernetes-dev/UqyPxAqwXLo/qAgRfoCBCAAJ
> [1] https://github.com/kubernetes/kubernetes/issues/19989
> [2] https://github.com/kubespray/kargo/blob/master/docs/roadmap.md
>
>
> Best Regards,
> Matthew Mosesohn
>

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To post to this group, send email to kuberne...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/1476713348.4897.13.camel%40redhat.com.
For more options, visit https://groups.google.com/d/optout.

[Brian Grant]

+eparis, who expressed interest in this

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

[Tomasz 'Zen' Napierala]

I would suggest to put it on sig CL agenda for next week and discuss the proposal. We’d like to hear more from different people.

Regards,

> To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-cluster...@googlegroups.com.
> To post to this group, send email to kubernetes-sig-c...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/CADkr4xnHRudrJS3C3oZuBq6FES2KFEBPL5kB4r%2Bo0HJd6Yf6sg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
>

> --
> You received this message because you are subscribed to the Google Groups "kubernetes-sig-cluster-lifecycle" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-cluster...@googlegroups.com.
> To post to this group, send email to kubernetes-sig-c...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/CAKCBhs71UYk7f-BHkZt9UUzHaWfAGAaKchm4ajO5haoDOasdhA%40mail.gmail.com.

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

--

Tomasz 'Zen' Napierala
Kubernetes Engineering - Poland