Kargo Incubation discussion

144 views
Skip to first unread message

Matthew Mosesohn

unread,
Oct 14, 2016, 12:24:08 PM10/14/16
to kuberne...@googlegroups.com
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=footer#!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

Bogdan Dobrelya

unread,
Oct 17, 2016, 6:50:10 AM10/17/16
to Kubernetes developer/contributor discussion
I support this request and kindly asking Kubernetes developers community for a guide. Please give us a hand and allow "ancillary projects that deploy Kubernetes" to co-exist  with the kubeadm LCM tool as those are *extensions* for things should normally be considered out of scope, like boring classic CM tasks that are still here and will be here. Let's leverage existing CM tools and keep the kubeadm lightweight and dedicated to its main tasks.

Eric Paris

unread,
Oct 17, 2016, 10:09:19 AM10/17/16
to Matthew Mosesohn, kuberne...@googlegroups.com
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

Tim Hockin

unread,
Oct 17, 2016, 10:37:39 AM10/17/16
to Eric Paris, kuberne...@googlegroups.com, Matthew Mosesohn
Cluster-lifecycle

--
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-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@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.
Reply all
Reply to author
Forward
This conversation is locked
You cannot reply and perform actions on locked conversations.
0 new messages