<div dir="ltr">At Mirantis we are playing with different technologies to explore possible ways of using containers. Recently we did some POC kind of work for integration existing OpenStack components with containers technologies. Here is a <a href="https://youtu.be/UthzO-xdoug">link</a> for a demo. In this POC Nova API can schedule a container via Nova Mesos driver which is quite similar to nova-docker concept. The most interesting part is that Neutron manages Docker networks and Cinder creates a volume which can be attached to the container. Mesos is not necessary here, so the same work can be done with existing nova-docker driver. <div><br></div><div>We did not try to address all possible cases for containers. This POC covers a very specific use cases when someone has a limited number of applications which can be executed in both VMs and containers. This application is self container so there is no needs in complex orchestration which Kubernetes or Marathon provides.</div><div><br></div><div>-Gosha</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 13, 2016 at 8:05 AM, Joshua Harlow <span dir="ltr"><<a href="mailto:harlowja@fastmail.com" target="_blank">harlowja@fastmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Thierry Carrez wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Fox, Kevin M wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think my head just exploded. :)<br>
<br>
That idea's similar to neutron sfc stuff, where you just say what<br>
needs to connect to what, and it figures out the plumbing.<br>
<br>
Ideally, it would map somehow to heat & docker COE & neutron sfc to<br>
produce a final set of deployment scripts and then just runs it<br>
through the meat grinder. :)<br>
<br>
It would be awesome to use. It may be very difficult to implement.<br>
<br>
If you ignore the non container use case, I think it might be fairly<br>
easily mappable to all three COE's though.<br>
</blockquote>
<br>
This feels like Heat with a more readable descriptive language. I don't<br>
really like this approach, because you end up with the lowest common<br>
denominator between COE's functionality. They are all different. And<br>
they are at the peak of the differentiation phase. The LCD is bound to<br>
be pretty basic.<br>
<br>
This approach may be attractive for us as infrastructure providers, but<br>
I also know this is not attractive to users who used Kubernetes before<br>
and wants to continue to use Kubernetes (and don't really want to care<br>
about whether OpenStack is running under the hood). They don't want to<br>
learn another descriptor language or API, they just want to learn the<br>
Kubernetes description model and API and take advantage of its unique<br>
capabilities.<br>
<br>
In summary, this may be a good solution for *existing* OpenStack users<br>
to start playing with containerized workloads. But it is not a good<br>
solution to attract the container cool kids to using OpenStack as their<br>
base infrastructure provider. For those we need to make it as<br>
transparent and simple to use their usual tools to deploy on top of<br>
OpenStack clouds. The more they can ignore we are there, the better.<br>
<br>
</blockquote>
<br></div></div>
I get the feeling of 'the more they can ignore we are there, the better.' but it just feels like at that point we have accepted our own fate in this arena vs trying to actually having an impact in it... Do others feel that it is already at the point where we can no longer attract the cool kids, is the tipping point of that happening already past?<br>
<br>
I'd like for openstack to still attract the cool kids, and not just attract the cool kids by accepting 'the more they can ignore we are there, the better' as our fate... I get that someone has to provide the equivalent of roads, plumbing and water but man, it feels like we can also provide other things still ;)<br>
<br>
-Josh<div class="HOEnZb"><div class="h5"><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><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><font color="#999999"><span style="background-color:rgb(255,255,255)">Georgy Okrokvertskhov<br>
Director of Performance Engineering,<br><span style="font-family:arial;font-size:small">OpenStack Platform Products,</span><br>
Mirantis</span><br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. +1 650 963 9828<br>
Mob. +1 650 996 3284</font><br></div></div></div></div>
</div>