[openstack-dev] [kolla][kolla-kubernete][tc][openstack-helm]propose retire kolla-kubernetes project

Steven Dake (stdake) stdake at cisco.com
Sat Mar 31 03:13:01 UTC 2018


On March 30, 2018 at 2:17:09 AM, Thierry Carrez (thierry at openstack.org<mailto:thierry at openstack.org>) wrote:

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)


Just got back from Ready Player One.  Good Movie!

Thanks Thierry for offering up your advocated position.

When contributors joined the Kolla project, we had a clear mission of providing containers and deployment tools.  Our ultimate objective was to make deployment *EASY* and solve from my perspective as PTL at the time what was OpenStack's number one pain point.

What you're asking is for people to divide their time between two separate projects and take responsibility for making containers functional for other projects.

Currently the core team has been generous with our time reviewing people's work in addition with +2/+As that want to use other deployment tools with Kolla containers, as referenced by TripleO, OSH, as well as a variety of other proprietary deployment tools.  Some of these contributors are also core reviewers themselves.  I don't expect this work would slow down under the current governance model of Kolla as we provide a very clear API to use when interfacing with Kolla.  Hence we do not *make it hard* to contribute to the containers deliverable.  The same cannot be said in your proposed governance model.

What your proposal asks is for contributors that came to scratch an itch to scratch a bunch of other itches that may not be to their interest, attend twice as meetings, attend twice as many PTG sessions or midcycles and grow some amount of expertise in understanding the various problems of other deployment projects.  Ultimately I have a big concern this would drive contributors away, rather than solve a perceived second order problem with our current governance model.

Regards,
-steve

[1] is for more reading about the structure or Kolla.

[1] https://www.ansible.com/blog/openstack-kolla

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/maila man/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180331/1630a5e6/attachment.html>


More information about the OpenStack-dev mailing list