<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mv="http://macVmlSchemaUri" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Title" content="">
<meta name="Keywords" content="">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:PMingLiU;
panose-1:2 2 5 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman";}
span.gmail-m4452651621995092624hoenzb
{mso-style-name:gmail-m_4452651621995092624hoenzb;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:Calibri;
color:windowtext;}
span.msoIns
{mso-style-type:export-only;
mso-style-name:"";
text-decoration:underline;
color:teal;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">I think both Pete and Steve make great points and it should be our long term vision. However, I lean more with Michael that we should make that a separate discussion, and it’s probably
better done further down the road. Yes, Kolla containers have come a long way, and the ABI has been stable for awhile, but the vast majority of that “for awhile” was with a single deployment tool: ansible. Now we have kolla-k8s and kolla-salt. Neither one
is fully featured yet as ansible, which to me means I don’t think we can say for sure that ABI won’t need to change as we try to support many deployment tools. (Someone remind me, didn’t kolla-mesos change the ABI?) Anyway, the point is I don’t think we’re
at a point of maturity to be certain the ABI won’t need changing. When we have 2-3 deployment tools with enough feature parity to say, “Any tool should be able to deploy kolla containers” then I think it make sense to have that discussion. I just don’t think
we’re there yet. And until the point, changes to the ABI will be quite painful if each project is in outside of the kolla umbrella, IMHO.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Thx,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">britt<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-family:Calibri;color:black">From: </span>
</b><span style="font-family:Calibri;color:black">Pete Birley <pete@port.direct><br>
<b>Reply-To: </b>"OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org><br>
<b>Date: </b>Thursday, January 5, 2017 at 6:47 PM<br>
<b>To: </b>"OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org><br>
<b>Subject: </b>Re: [openstack-dev] [tc][kolla] Adding new deliverables<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">Also coming from the perspective of a Kolla-Kubernetes contributor, I am worried about the scope that Kolla is extending itself to.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Moving from a single repo to multiple repo's has made the situation much better, but by operating under a single umbrella I feel that we may potentially be significantly limiting the potential for each deliverable. Alex Schultz, Steve and
Sam raise some good points here.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The interdependency between the projects is causing issues, the current reliance that Kolla-Kubernetes has on Kolla-ansible is both undesirable and unsustainable in my opinion. This is both because it limits the flexibility that we have
as Kolla-Kubernetes developers, but also because it places burden and rigidity on Kolla-Ansible. This will ultimately prevent both projects from being able to take advantage of the capabilities offered to them by the deployment mechanism they use.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Like Steve, I don't think the addition of Kolla-aSlt should affect me, and as a result don't feel I should have any say in the project. That said, I'd really like to see it happen in one form or another - as having a wide variety of complementary
projects and tooling for OpenStack deployment can only be a good thing for the community if correctly managed.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">When Kolla started it was very experimental, containers (In their modern form) were a relatively new construct, and it took on the audacious task of trying to package and deploy OpenStack using the tooling that was available at the time.
I really feel that this effort has succeeded admirably, and conversations like this are a result of that. Kolla is one of the most active projects in OpenStack, with two deployment mechanisms being developed currently, and hopefully to increase soon with a
salt based deployment and potentially even more on the horizon.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">With this in mind, I return to my original point and wonder if we may be better moving from our current structure of Kolla-deploy(x) to deploy(x)-Kolla and redefine the governance of these deliverables, turning them into freestanding projects.
I think this would offer several potential advantages, as it would allow teams to form tighter bonds with the tools and communities they use (ie Kubernetes/Helm, Ansible or Salt). This would also make it easier for these projects to use upstream components
where available (eg Ceph, RabbitMQ, and MariaDB) which are (and should be) in many cases better than the artifacts we can produce. To this end, I have been working with the Ceph community to get their Kubernetes Helm implementation to the point where we can
use it for our own work, and would love to see more of this. It benefits not only us by offloading support to the upstream project, but gives them a vested interest in supporting us and also helps provide better quality tooling for the entire open source ecosystem.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This should also allow Kolla itself to become much more streamlined, and focused simply on producing docker containers for consumption by the community, and make the artifacts produced potentially much less opinionated and more attractive
to other projects. And being honest, I have a real desire for this activity to eventually be taken on by the relevant OpenStack projects themselves - and would love to see Kolla help develop a framework that would allow projects to take ownership of the containerisation
of their output.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Sorry for such a long email - but this seems like a good opportunity to raise some of these issues that have been on my mind. In summary, if it doesn't affect me then I wish a Salt based Kolla deployment the best of success and hope to
see the project prosper so that we as OpenStack developers can all share from the increased experience and opportunities growing the community offers.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On Thu, Jan 5, 2017 at 9:43 PM, Steve Wilkerson <<a href="mailto:wilkers.steve@gmail.com">wilkers.steve@gmail.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">There are some interesting points in this topic. I agree entirely with Sam Yaple. It does not make sense to me to have kolla-ansible and kolla-kubernetes cores involved with the introduction of a new deliverable under the kolla umbrella.
A new deliverable (read: project, really) should not rely on a separate project to ratify its existence. I feel this is dangerous. I also feel looking at the different deployment methodologies scoped under the kolla project as competition or rivalry is folly.
I'm honestly a bit concerned about how broad the scope of the project kolla has become. I think the conversation of separating the deployment projects from the kolla umbrella is a conversation worth having at some point.
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The repo split was a step in the right direction, but currently the deliverables (4, if kolla-salt becomes a thing) are sharing a single PTL, a single IRC channel, and a single IRC weekly meeting. This has the potential of introducing
a significant amount of overhead for the overarching project as a whole. What happens if kolla-puppet becomes a thing? What if kolla-mesos was still about? I think we can all agree this gets out of hand quickly.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Yes, people are religious about the tools they use, and deployment tools are no different. I think scoping them all under the same umbrella project is a mistake in the long term. The folks that want to focus on Ansible should be able
to focus wholly on Ansible with like-minded folks, same for Salt, same for whatever. Having them remain together for the sake of sharing a name isn't sustainable in the long term -- let each do what they do well. As far as being able to talk and share experiences
in deployments or whatever, let's not act as if IRC channels have walls we can't reach across. As part of the kolla-kubernetes community, it's imperative that I can reach across the gap to work with people in the Helm and Kubernetes community. If the deployment
tools existed separately, there's nothing stopping them from asking either.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">But in regards to the question, if kolla-salt is to be a thing, I think the PTL and the kolla team proper can decide that. As a contributor for kolla-kubernetes, it does not and should not affect me.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Jan 5, 2017 at 3:14 PM, Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">Excerpts from Michał Jastrzębski's message of 2017-01-05 11:45:49 -0800:<span style="font-family:PMingLiU"><br>
</span>> I think total separation of projects would require much larger<span style="font-family:PMingLiU"><br>
</span>> discussion in community. Currently we agreed on having kolla-ansible<span style="font-family:PMingLiU"><br>
</span>> and kolla-k8s to be deliverables under kolla umbrella from historical<br>
> reasons. Also I don't agree that there is "little or no overlap" in<br>
> teams, in fact there is ton of overlap, just not 100%. Many<br>
> contributors (myself included) jump between deliverables today.<br>
<br>
OK, that's good to know. It wasn't clear from some of the initial<br>
messages in this thread, which seemed to imply otherwise.<br>
<span style="color:#888888"><br>
<span class="gmail-m4452651621995092624hoenzb">Doug</span></span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<div>
<div>
<div>
<div>
<div>
<table class="MsoNormalTable" border="0" cellpadding="0" width="450" style="width:337.5pt">
<tbody>
<tr>
<td width="90" valign="top" style="width:67.5pt;padding:0in 0in 0in 0in">
<p style="mso-margin-top-alt:5.0pt;margin-right:7.5pt;margin-bottom:7.5pt;margin-left:0in;line-height:9.0pt">
<span style="font-size:7.5pt;font-family:Helvetica;color:black"><a href="https://port.direct"><span style="text-decoration:none"><img border="0" width="80" height="80" id="_x0000_i1025" src="https://raw.githubusercontent.com/encharm/Font-Awesome-SVG-PNG/master/black/png/256/anchor.png" alt="ort.direct"></span></a><o:p></o:p></span></p>
</td>
<td width="370" nowrap="" style="width:277.5pt;padding:0in 0in 0in 0in">
<p style="margin-bottom:7.5pt;line-height:9.0pt"><b><span style="font-size:7.5pt;font-family:Helvetica;color:#212121">Pete Birley</span></b><span style="font-size:7.5pt;font-family:Helvetica;color:#212121"> / Director <br>
<a href="mailto:pete@port.direct"><span style="color:#477CCC;text-decoration:none">pete@port.direct</span></a> / +447446862551<o:p></o:p></span></p>
<p style="margin-bottom:7.5pt;line-height:9.0pt"><strong><span style="font-size:7.5pt;font-family:Helvetica;color:#212121">PORT.</span></strong><b><span style="font-size:7.5pt;font-family:Helvetica;color:#212121">DIRECT</span></b><span style="font-size:7.5pt;font-family:Helvetica;color:black"> <br>
</span><span style="font-size:7.5pt;font-family:Helvetica;color:#212121">United Kingdom</span><span style="font-size:7.5pt;font-family:Helvetica;color:black"> <br>
<a href="https://port.direct"><span style="color:#477CCC;text-decoration:none">https://port.direct</span></a><o:p></o:p></span></p>
</td>
</tr>
<tr>
<td colspan="2" style="padding:0in 0in 0in 0in"></td>
</tr>
<tr>
<td colspan="2" style="padding:0in 0in 0in 0in"></td>
</tr>
<tr>
<td colspan="2" style="padding:0in 0in 0in 0in">
<p style="line-height:9.0pt"><span style="font-size:7.0pt;font-family:Helvetica;color:#212121">This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure,
dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. Port.direct is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this
message and any attachment are solely those of the author and do not necessarily represent those of the company.<o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>