<div dir="ltr"><div><div>Hi all,<br></div>it looks like Glare may cover some (or all) your use cases. <br>To understand the functionality proposed to Glare I suggest you to read this:<br><a href="https://review.openstack.org/#/c/283136/">https://review.openstack.org/#/c/283136/</a>.<br></div><div>It would be cool if Glare supports everything you need.  If you need something else please add a comment, we will try to consider your requirements.<br></div><div>You can also contact me(kairat), Mike Fedosin (mfedosin) and Nikhil Komawar (nikhil) for any questions related to Glare.<br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Best regards,<div>Kairat Kushaev</div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Jun 14, 2016 at 10:43 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"><div class="HOEnZb"><div class="h5">On 13/06/16 18:46 +0000, Hongbin Lu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-----Original Message-----<br>
From: Sudipto Biswas [mailto:<a href="mailto:sbiswas7@linux.vnet.ibm.com" target="_blank">sbiswas7@linux.vnet.ibm.com</a>]<br>
Sent: June-13-16 1:43 PM<br>
To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [Higgins][Zun] Project roadmap<br>
<br>
<br>
<br>
On Monday 13 June 2016 06:57 PM, Flavio Percoco wrote:<br>
> On 12/06/16 22:10 +0000, Hongbin Lu wrote:<br>
>> Hi team,<br>
>><br>
>> During the team meetings these weeks, we collaborated the initial<br>
>> project roadmap. I summarized it as below. Please review.<br>
>><br>
>> * Implement a common container abstraction for different container<br>
>> runtimes. The initial implementation will focus on supporting basic<br>
>> container operations (i.e. CRUD).<br>
><br>
> What COE's are being considered for the first implementation? Just<br>
> docker and kubernetes?<br>
</blockquote>
[Hongbin Lu] Container runtimes, docker in particular, are being considered for the first implementation. We discussed how to support COEs in Zun but cannot reach an agreement on the direction. I will leave it for further discussion.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
>> * Focus on non-nested containers use cases (running containers on<br>
>> physical hosts), and revisit nested containers use cases (running<br>
>> containers on VMs) later.<br>
>> * Provide two set of APIs to access containers: The Nova APIs and<br>
the<br>
>> Zun-native APIs. In particular, the Zun-native APIs will expose full<br>
>> container capabilities, and Nova APIs will expose capabilities that<br>
>> are shared between containers and VMs.<br>
><br>
> - Is the nova side going to be implemented in the form of a Nova<br>
> driver (like ironic's?)? What do you mean by APIs here?<br>
</blockquote>
[Hongbin Lu] Yes, the plan is to implement a Zun virt-driver for Nova. The idea is similar to Ironic.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> - What operations are we expecting this to support (just CRUD<br>
> operations on containers?)?<br>
</blockquote>
[Hongbin Lu] We are working on finding the list of operations to support. There is a BP for tracking this effort: <a href="https://blueprints.launchpad.net/zun/+spec/api-design" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/zun/+spec/api-design</a> .<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> I can see this driver being useful for specialized services like<br>
Trove<br>
> but I'm curious/concerned about how this will be used by end users<br>
> (assuming that's the goal).<br>
</blockquote>
[Hongbin Lu] I agree that end users might not be satisfied by basic container operations like CRUD. We will discuss how to offer more to make the service to be useful in production.<br>
</blockquote>
<br></div></div>
I'd probably leave this out for now but this is just my opinion. Personally, I<br>
think users, if presented with both APIs - nova's and Zun's - they'll prefer<br>
Zun's.<br>
<br>
Specifically, you don't interact with a container the same way you interact with<br>
a VM (but I'm sure you know all these way better than me). I guess my concern is<br>
that I don't see too much value in this other than allowing specialized services<br>
to run containers through Nova.<span class=""><br>
<br>
<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">
><br>
><br>
>> * Leverage Neutron (via Kuryr) for container networking.<br>
>> * Leverage Cinder for container data volume.<br>
>> * Leverage Glance for storing container images. If necessary,<br>
>> contribute to Glance for missing features (i.e. support layer of<br>
>> container images).<br>
><br>
> Are you aware of <a href="https://review.openstack.org/#/c/249282/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/249282/</a> ?<br>
This support is very minimalistic in nature, since it doesn't do<br>
anything beyond just storing a docker FS tar ball.<br>
I think it was felt that, further support for docker FS was needed.<br>
While there were suggestions of private docker registry, having<br>
something in band (w.r.t openstack) maybe desirable.<br>
</blockquote>
[Hongbin Lu] Yes, Glance doesn't support layer of container images which is a missing feature.<br>
</blockquote>
<br></span>
Yup, I didn't mean to imply that would do it all for you rather that there's been<br>
some progress there. As far as layered containers goes, you might want to look<br>
into Glare.<br>
<br>
Flavio<div class="HOEnZb"><div class="h5"><br>
<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">
>> * Support enforcing multi-tenancy by doing the following:<br>
>> ** Add configurable options for scheduler to enforce neighboring<br>
>> containers belonging to the same tenant.<br>
>> ** Support hypervisor-based container runtimes.<br>
>><br>
>> The following topics have been discussed, but the team cannot reach<br>
>> consensus on including them into the short-term project scope. We<br>
>> skipped them for now and might revisit them later.<br>
>> * Support proxying API calls to COEs.<br>
><br>
> Any link to what this proxy will do and what service it'll talk to?<br>
> I'd generally advice against having proxy calls in services. We've<br>
> just done work in Nova to deprecate the Nova Image proxy.<br>
</blockquote>
[Hongbin Lu] Maybe "proxy" is not the right word. What I mean is to translate the request to API calls of COEs. For example, users request to create a container in Zun, then Zun creates a single-container pod in k8s.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
>> * Advanced container operations (i.e. keep container alive, load<br>
>> balancer setup, rolling upgrade).<br>
>> * Nested containers use cases (i.e. provision container hosts).<br>
>> * Container composition (i.e. support docker-compose like DSL).<br>
>><br>
>> NOTE: I might forgot and mis-understood something. Please feel free<br>
>> to point out if anything is wrong or missing.<br>
><br>
> It sounds you've got more than enough to work on for now, I think<br>
it's<br>
> fine to table these topics for now.<br>
><br>
> just my $0.02<br>
> Flavio<br>
><br>
><br>
><br>
><br>
______________________________________________________________________<br>
> ____ OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <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>
___<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: OpenStack-dev-<br>
<a href="http://request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">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>
</blockquote>
<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>
</blockquote>
<br></div></div><span class="HOEnZb"><font color="#888888">
-- <br>
@flaper87<br>
Flavio Percoco<br>
</font></span><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></blockquote></div><br></div>