<div dir="ltr"><div style="font-family:monospace,monospace" class="gmail_default"><p id="gmail-docs-internal-guid-7c686a65-3189-4032-0f26-c9511bbb38d2" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" dir="ltr"><span style="font-size:14.6667px;font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">>1. Alter the mission statement of fuel to match the reality being</span></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" dir="ltr"><span style="font-size:14.6667px;font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">>published by the press and Mirantis's executive team</span></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" dir="ltr"><span style="font-size:14.6667px;font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">>2. Include these non-experimental repos in the projects.yaml governance</span></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" dir="ltr"><span style="font-size:14.6667px;font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">>Repository</span></p><br><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" dir="ltr"><span style="font-size:14.6667px;font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Frankly, I don’t understand what part of the press release contradicts with Fuel mission. </span></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" dir="ltr"><span style="font-size:14.6667px;font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Current Fuel mission is “To streamline and accelerate the process of deploying, testing and maintaining various configurations of OpenStack at scale.” which means we are not bound to any specific technology when deploying OpenStack. </span></p><br><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" dir="ltr"><span style="font-size:14.6667px;font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">At the moment Fuel deploys RPM/DEB packages using Puppet and Fuel specific orchestration mechanism. We are not going to drop this approach immediately, it works quite well and we are working hard to make things better (including ability to upgrade). But we also keep in mind that technologies are constantly changing and we’d like to benefit of this progress. That is why we are now looking at Docker containers and Kubernetes. Our users know that it is not our first experience of trying to use containers. Fuel releases prior to 9.0 used to deploy Fuel services in containers on the Fuel admin node. </span></p><br><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" dir="ltr"><span style="font-size:14.6667px;font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Many of you know how difficult it is to upgrade OpenStack clusters. We hope that containers could help us to solve not all but some of problems that we encounter when upgrading cluster. Maintaining and hence upgrade of OpenStack clusters is a part of Fuel mission and we are just trying to find a way how to do things. </span></p><br><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" dir="ltr"><span style="font-size:14.6667px;font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Why not Kolla but Fuel-ccp? It is not a secret that Fuel is driven by Mirantis. At Mirantis we deploy and maintain OpenStack. In attempts to find a way how to make OpenStack easily maintainable, some of Mirantis folks spent some time to contribute to Kolla and Mesos. But there were some concerns that were discussed several times (including this Kolla spec </span><a style="text-decoration:none" href="https://review.openstack.org/#/c/330575"><span style="font-size:14.6667px;font-family:arial;color:rgb(17,85,204);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:underline;vertical-align:baseline">https://review.openstack.org/#/c/330575</span></a><span style="font-size:14.6667px;font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">) that would make it not so easy to use Kolla containers for our use cases. Fuel-ccp is just an attempt to address these concerns. Frankly, I don’t see anything bad in having more than one set of container images (like we have more than one set of RPM/DEB distributions).</span></p><br><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" dir="ltr"><span style="font-size:14.6667px;font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Those concerns are, for example, container images should not be bound to any specific deployment technology. Containers in some sense are a similar concept to RPM/DEB packages and it does not matter what deployment tool (puppet, ansible) one uses to install them. There should be mature CI pipeline for building/testing/publishing images. There should be a convenient way (kind of DSL) to deal with dozens of images. I’d like to avoid discussing this here once again. </span></p><br><span style="font-size:14.6667px;font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Fuel-ccp repositories are public, everyone is welcome to participate. I don’t see where we violate “4 opens”. These repos are now experimental. At the moment the team is working on building CI pipeline and developing functional tests that are to be run as a part of CI process. These repos are not to be a part of Fuel Newton release. From time to time we add and retire git repos and it is a part of development process. Not all these repos are to become a part of Big tent.<br><br><br></span></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div>Vladimir Kozhukalov</div></div></div>
<br><div class="gmail_quote">On Thu, Jul 28, 2016 at 7:45 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"><span class=""><br>
<br>
On 7/27/16, 2:12 PM, "Jay Pipes" <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
<br>
>On 07/27/2016 04:42 PM, Ed Leafe wrote:<br>
>> On Jul 27, 2016, at 2:42 PM, Fox, Kevin M <<a href="mailto:Kevin.Fox@pnnl.gov">Kevin.Fox@pnnl.gov</a>> wrote:<br>
>><br>
>>> Its not an "end user" facing thing, but it is an "operator" facing<br>
>>>thing.<br>
>><br>
>> Well, the end user for Kolla is an operator, no?<br>
>><br>
>>> I deploy kolla containers today on non kolla managed systems in<br>
>>>production, and rely on that api being consistent.<br>
>>><br>
>>> I'm positive I'm not the only operator doing this either. This sounds<br>
>>>like a consumable api to me.<br>
>><br>
>> I don¹t think that an API has to be RESTful to be considered an<br>
>>interface for we should avoid duplication.<br>
><br>
>Application *Programming* Interface. There's nothing that is being<br>
>*programmed* or *called* in Kolla's image definitions.<br>
><br>
>What Kolla is/has is not an API. As Stephen said, it's more of an<br>
>Application Binary Interface (ABI). It's not really an ABI, though, in<br>
>the traditional sense of the term that I'm used to.<br>
><br>
>It's an agreed set of package bases, installation procedures/directories<br>
>and configuration recipes for OpenStack and infrastructure components.<br>
<br>
</span>Jay,<br>
<br>
>From my perspective, this isn't about ABI proliferation or competition.<br>
This is about open public discourse.<br>
<br>
It is the responsibility of all community members to protect the four<br>
opens.<br>
<br>
Given the intent of fuel-ccp to fully adopt K8S into Fuel described here:<br>
<a href="https://techcrunch.com/2016/07/25/openstack-will-soon-be-able-to-run-on-top
-of-kubernetes/" rel="noreferrer" target="_blank">https://techcrunch.com/2016/07/25/openstack-will-soon-be-able-to-run-on-top<br>
-of-kubernetes/</a><br>
<br>
<br>
It is hard to understand the arguments in the reviews related to "this is<br>
an experimental project, so its not targeted towards big tent" yet Boris<br>
wrote in that press release its Fuel's next big thing.<br>
<br>
I raised the objection early on that a mission statement change was needed<br>
by Fuel if they wanted to proceed down this path, to which I was told K8S<br>
support is not going into big tent.<br>
<br>
As a result of Mirantis's change in mind about fuel-ccp being NOT<br>
experimental and being targeted for big tent, I'd like the record set<br>
straight in the governance repository since the intentions are being<br>
published in the press and the current intentions of this project are<br>
public.<br>
<br>
I could see how people could perceive many violations of the four opens in<br>
all of the activities related to the fuel-ccp project. We as a community<br>
value open discourse because we are all intelligent human beings. We<br>
value honesty and integrity because trust is the foundation of how our<br>
community operates. I feel the best way for Fuel to repair the perceived<br>
violations of the four opens going forward is to:<br>
<br>
1. Alter the mission statement of fuel to match the reality being<br>
published by the press and Mirantis's executive team<br>
2. Include these non-experimental repos in the projects.yaml governance<br>
repository<br>
<br>
That would satisfy my four opens concerns.<br>
<br>
If the Fuel PTL doesn't want to do these two things, I'd like a public<br>
explanation as to why from Vladimir who thus far has remained quiet on<br>
this thread.<br>
<br>
Thanks<br>
-steve<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
><br>
>I see no reason for the OpenStack community to standardize on those<br>
>things, frankly. It's like asking RedHat and Canonical to agree to "just<br>
>use RPM" as their package specification format. I wonder how that<br>
>conversation would go.<br>
><br>
>Best,<br>
>-jay<br>
><br>
>__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>