Open Stack

Richard Wellum wrote:
> So as a current Kolla-Kubernetes Core - I have a slightly different
> opinion than most, I'll try to verbalize it coherently.

Thanks Rich for posting this -- I was really feeling like we missed part
of the story.

> Lets talk about what Kolla is:
> 
> Kolla is a project that builds OpenStack docker images, stores them on
> dockerhub, and provides tools to build your own images from your own
> source. Both the images and the tools it provides, are widely used, very
> popular and extremely stable; TripleO, openstack-helm and kolla-ansible
> to name a few are all deployment methods that use Kolla.
> 
> Kolla has two sub-projects, that both revolve around deployment methods;
> kolla-ansible and kolla-kubernetes. Kolla-ansible is proven, stable and
> used by many in the industry. Part of Kolla's quality is it's rock-solid
> dependability in many scenarios. As Kubernetes took over most of the COE
> world, it's only correct that the Kolla team created this sub-project;
> if swarm became suddenly very popular then we should create a
> kolla-swarm sub-project.
> 
> So if we abandon kolla-kubernetes ('sunset' seems much more romantic
> admittedly) - we are abandoning the core Kolla team's efforts in this
> space. No matter how good openstack-helm is (and I've deployed it, know
> a lot of the cores and it's truly excellent and well driven), what
> happens down the line if openstack-helm decide to move on from Kolla -
> say focussing on Loci images or a new flavor that comes along? Then
> Kolla the core project, will no longer have any validation of it's
> docker images/containers running on Kubernetes. That to me is the big
> risk here.

There is a 3rd option, which I've been advocating for a while.

The tension here lies in the fact that the Kolla team is both a
low-level provider (Kolla the docker image provider) and a higher-level
deployment provider (kolla-ansible, kolla-k8s). The low-level images are
used outside of the team (TripleO, openstack-helm), in the team
(kolla-ansible) and in the team but by a different group (kolla-k8s).

The proposals on the table only partly resolve that tension. Keeping
kolla-k8s in kolla, spinning it out or merging it with OSH still make
kolla both a low-level and a high-level provider. As long as
kolla-ansible shares naming and is produced by the exact same team
producing Kolla itself, anything else than kolla-ansible will stay a
second-class consumer, breeding validation fears like the one described
above.

For the structure to match the technical goals, I wonder if "Kolla"
should not focus on low-level image production, with the various
higher-level Kolla consumers being set up as separate projects on an
equal footing. I understand that Kolla and Kolla-Ansible are currently
mostly the same group of people, but nothing in OpenStack prevents
anyone from being part of two teams. Setting up discrete groups would
actually encourage people interested in Kolla but not so much in
Kolla-Ansible to join the Kolla team. It would encourage the Kolla team
to treat all consumers equally and test their images on those various
consumers equally.

So my 3rd option would be to split the current Kolla team into three
teams with different names, matching the three deliverables that this
team currently has. Then if kolla-k8s needs to be sunset or merged with
OSH, so be it.

-- 
Thierry Carrez (ttx)