On March 30, 2018 at 2:17:09 AM, Thierry Carrez (thie...@openstack.org<mailto:thie...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/maila man/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
