<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 28, 2016 at 10:52 AM, Flavio Percoco <span dir="ltr"><<a href="mailto:flavio@redhat.com" target="_blank">flavio@redhat.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="">On 28/07/16 15:48 +0300, Vladimir Kozhukalov wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1. Alter the mission statement of fuel to match the reality being<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
published by the press and Mirantis's executive team<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. Include these non-experimental repos in the projects.yaml governance<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Repository<br>
</blockquote>
<br>
Frankly, I don’t understand what part of the press release contradicts with<br>
Fuel mission.<br>
<br>
Current Fuel mission is “To streamline and accelerate the process of<br>
deploying, testing and maintaining various configurations of OpenStack at<br>
scale.” which means we are not bound to any specific technology when<br>
deploying OpenStack.<br>
</blockquote>
<br></span>
TBH, I also think this statement is broad enough to cover containers. Unless the<br>
request is to explicitly mention "containers" in the mission statement, I think<br>
there's no need to change it. I'd also be against having "containers" being<br>
explicitly mentioned in Fuel's statement, FWIW. I don't think it'd be of any<br>
benefit/use. Unless I'm missing something fundamental here, of course.</blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I agree that the current mission statement seems fine.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
At the moment Fuel deploys RPM/DEB packages using Puppet and Fuel specific<br>
orchestration mechanism. We are not going to drop this approach<br>
immediately, it works quite well and we are working hard to make things<br>
better (including ability to upgrade). But we also keep in mind that<br>
technologies are constantly changing and we’d like to benefit of this<br>
progress. That is why we are now looking at Docker containers and<br>
Kubernetes. Our users know that it is not our first experience of trying to<br>
use containers. Fuel releases prior to 9.0 used to deploy Fuel services in<br>
containers on the Fuel admin node.<br>
<br>
Many of you know how difficult it is to upgrade OpenStack clusters. We hope<br>
that containers could help us to solve not all but some of problems that we<br>
encounter when upgrading cluster. Maintaining and hence upgrade of<br>
OpenStack clusters is a part of Fuel mission and we are just trying to find<br>
a way how to do things.<br>
<br>
Why not Kolla but Fuel-ccp? It is not a secret that Fuel is driven by<br>
Mirantis. At Mirantis we deploy and maintain OpenStack. In attempts to find<br>
a way how to make OpenStack easily maintainable, some of Mirantis folks<br>
spent some time to contribute to Kolla and Mesos. But there were some<br>
concerns that were discussed several times (including this Kolla spec<br>
<a href="https://review.openstack.org/#/c/330575" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/330575</a>) that would make it not so easy to<br>
use Kolla containers for our use cases. Fuel-ccp is just an attempt to<br>
address these concerns. Frankly, I don’t see anything bad in having more<br>
than one set of container images (like we have more than one set of RPM/DEB<br>
distributions).<br>
</blockquote>
<br></span>
++<br></blockquote></div><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I think the project seems fine. They are clearly aware of Kolla. If they don't want to use it (for whatever the reason), I don't think it matters. OpenStack deployment is far from a well solved problem. We have plenty of overlapping deployment related projects and I'm happy to see that continue. Ongoing experimentation with different approaches is a good thing here.</div></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">To summarize, I see all actions taken so far by the Fuel team as fine. I see no need to change anything in governance. They are free to add it as an official deliverable if and when they choose to do so. Even if they have a vision of these things becoming official and supported in the future, that does not mean they must mark them that way today.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:arial,sans-serif">-- </span><br></div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><font face="arial, helvetica, sans-serif">Russell Bryant</font></div></div></div></div></div>
</div></div>