<div dir="ltr"><div>Steve,</div><div><br></div><div>As a contributor to a kolla-* project, I disagree with your view that Kolla is not "themed". The more I work in the Kolla community, it's become apparent that Kolla is operating under the "Deploy containers" theme, and you state as much in your reply.<br></div><div><br></div><div>I also disagree that separating the kolla-* projects somehow introduces competition between them. Some operators would like to use Ansible for orchestration because it's a tool their familiar with and love. Others may want to use Salt. If kolla-puppet became a thing, I'm sure some people love Puppet enough to run with that tool. Tools are religious. The contributors who wish to work on a deployment project centered around their favorite tool should be free to do so without influence from those who enjoy a different orchestration tool. We can both agree here that the end goal is to deploy the Kolla containers specifically. The orchestration methods for deploying those containers goes beyond slightly different interests. For example, my interest lies solely in working with kolla-kubernetes. I have no desire to work with kolla-ansible or kolla-{whatever else may come along} currently. Some individuals do have that desire, and contributing to different projects is absolutely possible. The argument that splitting the projects into their own team produces competition in regards to choosing a tool doesn't make senes to me -- the end goal is the same. Having these deployment projects under the Kolla umbrella is no different -- an operator will still choose the tool they want to use.</div><div><br></div><div>I agree competition is a good thing, and as long as separate projects have significant technical differences, competition should be encouraged. It allows the community as a whole to see what works well, what doesn't work well, and whether we're overlooking requirements that need addressed. However, to follow up your support for competition with the claim we should end competition on deployment tools for containers confuses me. One of the primary concerns I have with the Kolla project currently is the idea it needs to be the go-to project for containerized OpenStack deployments, and everyone who wishes for such a deployment should work exclusively under Kolla. I will say this: If an organization is seeking a containerized deployment of OpenStack using the Kolla images, they should collaborate and work closely with the Kolla community and the kolla-* deployment tool they're aiming to use. However, thinking the Kolla project as it exists today is the single source of truth for a containerized deployment of OpenStack does a huge disservice both to the community Kolla has today and to the users who have a use case that isn't addressed by Kolla. While Kolla wants to be flexible and allow for any orchestration method, some users may want something that's very targeted to their needs. That's perfectly okay. Trying to force groups with different needs to work under one umbrella project leads to distraction and will invariably lead to a sub-optimal solution for all parties involved.</div><div><br></div><div>I will agree with you that Kolla is warm and open to new contributors -- I'm a new contributor, and I received encouraging support from members on the team in regards to getting up to speed and looking at the picture of where Kolla was going. I'm positive that anyone who wants to contribute to Kolla and the Kolla-* projects would be welcome all the same, regardless of whether the projects existed under one umbrella or separately.</div><div><br></div><div>I honestly don't see how the Kolla-* projects existing separately sows discord between deployment tool projects in the big tent. Once again -- Kolla is focused entirely on deploying the Kolla images exclusively while remaining pluggable on the orchestration tool end. As it stands, there are no other deployment tools that share the same mission of "Kolla images only, using deployment tool {x}" that I'm aware of.</div><div><br></div><div>You mention this weakens Kolla and doesn't help OpenStack much. On the contrary, I see splitting the projects off as helping Kolla, Kolla-*, and OpenStack immensely. This reduces the strain on Kolla cores and the proposed role they play in adding Kolla deliverables. Kolla cores can focus exclusively on maintaining and improving the consumable artifacts the Kolla-* projects require. The Kolla-* projects benefit by driving their project forward independent of other deployment tools. They can build a core team focused around their use case, and they can elect a PTL that will drive their project forward in a way that best suits their needs. I fail to see how one PTL overlooking different deployment tools can honestly have the best interest of all Kolla-* projects in mind, unless you're implying we only choose someone who's familiar with each and every one of them if things remain the same. Finally, as the projects evolve and are able to better target their unique means to the same end, OpenStack benefits all around.</div><div><br></div><div>I'd also like to see people with the same targeted means for achieving the same end working together. I think splitting the Kolla-* out into their own projects and letting the contributors interested in those projects work on them separately best enables that goal, not having them operate under one, large umbrella.</div><div><br></div><div> </div><div><br></div><div> </div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 11, 2017 at 8:50 AM, Steven Dake (stdake) <span dir="ltr"><<a href="mailto:stdake@cisco.com" target="_blank">stdake@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thierry,<br>
<br>
I am not a big fan of the separate gerrit teams we have instituted inside the Kolla project. I always believed we should have one core reviewer team responsible for all deliverables to avoid not just the appearance but the reality that each team would fragment the overall community of people working on Kolla containers and deployment tools. This is yet another reason I didn’t want to split the repositories into separate deliverables in the first place – since it further fragments the community working on Kolla deliverables.<br>
<br>
When we made our original mission statement, I originally wanted it scoped around just Ansible and Docker. Fortunately, the core review team at the time made it much more general and broad before we joined the big tent. Our mission statement permits multiple different orchestration tools.<br>
<br>
Kolla is not “themed”, at least to me. Instead it is one community with slightly different interests (some people work on Ansible, some on Kubernetes, some on containers, some on all 3, etc). If we break that into separate projects with separate PTLs, those projects may end up competing with each other (which isn’t happening now inside Kolla). I think competition is a good thing. In this case, I am of the opinion it is high time we end the competition on deployment tools related to containers and get everyone working together rather than apart. That is, unless those folks want to “work apart” which of course is their prerogative. I wouldn’t suggest merging teams today that are separate that don’t have a desire to merge. That said, Kolla is very warm and open to new contributors so hopefully no more new duplicate effort solutions are started.<br>
<br>
Siloing the deliverables into separate teams I believe would result in the competition I just mentioned, and further discord between the deployment tool projects in the big tent. We need consolidation around people working together, not division. Division around Kolla weakens Kolla specifically and doesn’t help out OpenStack all that much either.<br>
<br>
The idea of branding or themes is not really relevant to me. Instead this is all about the people producing and consuming Kolla. I’d like these folks to work together as much as feasible. Breaking a sub-community apart (in this case Kolla) into up to 4 different communities with 4 different PTLs sounds wrong to me.<br>
<br>
I hope my position is clear ☺ If not, feel free to ask any follow-up questions.<br>
<br>
Regards<br>
-steve<br>
<span class="im HOEnZb"><br>
<br>
-----Original Message-----<br>
From: Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>><br>
Organization: OpenStack<br>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
Date: Wednesday, January 11, 2017 at 4:21 AM<br>
To: "<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.<wbr>openstack.org</a>><br>
Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables<br>
<br>
</span><div class="HOEnZb"><div class="h5"> Michał Jastrzębski wrote:<br>
> I created CIVS poll with options we discussed. Every core member should<br>
> get link to poll voting, if that's not the case, please let me know.<br>
<br>
Just a quick sidenote to explain how the "big-tent" model of governance<br>
plays in here...<br>
<br>
In the previous project structure model, we had "programs". If you<br>
wanted to do networking stuff, you had to join the Networking program<br>
(neutron). If you worked on object storage, you had to join the Object<br>
Storage program (swift). The main issue with this model is that it<br>
prevented alternate approaches from emerging (as a program PTL could<br>
just refuse its emergence to continue to "own" that space). It also<br>
created weird situations where there would be multiple distinct groups<br>
of people in a program, but a single PTL to elect to represent them all.<br>
That created unnecessary political issues within programs and tension<br>
around PTL election.<br>
<br>
Part of the big-tent project structure reform was to abolish programs<br>
and organize our work around "teams", rather than "themes". Project<br>
teams should be strongly aligned with a single team of people that work<br>
together. That allowed some amount of competition to emerge (we still<br>
try to avoid "gratuitous duplication of effort"), but most importantly<br>
made sure groups of people could "own" their work without having to<br>
defer to an outside core team or PTL. So if you have a distinct team, it<br>
should be its own separate project team with its own PTL. There is no<br>
program or namespace anymore. As a bonus side-effect, it made sure teams<br>
would not indefinitely grow, and we all know that it's difficult to grow<br>
core teams (and trust) beyond a certain point.<br>
<br>
This is why we have multiple packaging project teams, each specialized<br>
in a given package orchestration mechanism, rather than have a single<br>
"Packaging" program with a single PTL and Ansible / Puppet / Chef<br>
fighting in elections to get their man at the helm. This is why the<br>
Storlets team, while deeply related to Swift and in very good<br>
collaboration terms with them, was set up as a separate project team.<br>
Different people, different team.<br>
<br>
The fact that you're having hard discussions in Kolla about "adding new<br>
deliverables" produced by distinct groups of people indicates that you<br>
may be using Kolla as an old-style "program" rather than as a single<br>
team. Why not set them up as separate project teams ? What am I missing<br>
here ?<br>
<br>
--<br>
Thierry Carrez (ttx)<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>