Open Stack

Hi all,
it looks like Glare may cover some (or all) your use cases.
To understand the functionality proposed to Glare I suggest you to read
this:
https://review.openstack.org/#/c/283136/.
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.
You can also contact me(kairat), Mike Fedosin (mfedosin) and Nikhil Komawar
(nikhil) for any questions related to Glare.

Best regards,
Kairat Kushaev

On Tue, Jun 14, 2016 at 10:43 AM, Flavio Percoco <flavio at redhat.com> wrote:

> On 13/06/16 18:46 +0000, Hongbin Lu wrote:
>
>>
>>
>> -----Original Message-----
>>> From: Sudipto Biswas [mailto:sbiswas7 at linux.vnet.ibm.com]
>>> Sent: June-13-16 1:43 PM
>>> To: openstack-dev at lists.openstack.org
>>> Subject: Re: [openstack-dev] [Higgins][Zun] Project roadmap
>>>
>>>
>>>
>>> On Monday 13 June 2016 06:57 PM, Flavio Percoco wrote:
>>> > On 12/06/16 22:10 +0000, Hongbin Lu wrote:
>>> >> Hi team,
>>> >>
>>> >> During the team meetings these weeks, we collaborated the initial
>>> >> project roadmap. I summarized it as below. Please review.
>>> >>
>>> >> * Implement a common container abstraction for different container
>>> >> runtimes. The initial implementation will focus on supporting basic
>>> >> container operations (i.e. CRUD).
>>> >
>>> > What COE's are being considered for the first implementation? Just
>>> > docker and kubernetes?
>>>
>> [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.
>>
>> >
>>> >> * Focus on non-nested containers use cases (running containers on
>>> >> physical hosts), and revisit nested containers use cases (running
>>> >> containers on VMs) later.
>>> >> * Provide two set of APIs to access containers: The Nova APIs and
>>> the
>>> >> Zun-native APIs. In particular, the Zun-native APIs will expose full
>>> >> container capabilities, and Nova APIs will expose capabilities that
>>> >> are shared between containers and VMs.
>>> >
>>> > - Is the nova side going to be implemented in the form of a Nova
>>> > driver (like ironic's?)? What do you mean by APIs here?
>>>
>> [Hongbin Lu] Yes, the plan is to implement a Zun virt-driver for Nova.
>> The idea is similar to Ironic.
>>
>> >
>>> > - What operations are we expecting this to support (just CRUD
>>> > operations on containers?)?
>>>
>> [Hongbin Lu] We are working on finding the list of operations to support.
>> There is a BP for tracking this effort:
>> https://blueprints.launchpad.net/zun/+spec/api-design .
>>
>> >
>>> > I can see this driver being useful for specialized services like
>>> Trove
>>> > but I'm curious/concerned about how this will be used by end users
>>> > (assuming that's the goal).
>>>
>> [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.
>>
>
> I'd probably leave this out for now but this is just my opinion.
> Personally, I
> think users, if presented with both APIs - nova's and Zun's - they'll
> prefer
> Zun's.
>
> Specifically, you don't interact with a container the same way you
> interact with
> a VM (but I'm sure you know all these way better than me). I guess my
> concern is
> that I don't see too much value in this other than allowing specialized
> services
> to run containers through Nova.
>
>
> >
>>> >
>>> >> * Leverage Neutron (via Kuryr) for container networking.
>>> >> * Leverage Cinder for container data volume.
>>> >> * Leverage Glance for storing container images. If necessary,
>>> >> contribute to Glance for missing features (i.e. support layer of
>>> >> container images).
>>> >
>>> > Are you aware of https://review.openstack.org/#/c/249282/ ?
>>> This support is very minimalistic in nature, since it doesn't do
>>> anything beyond just storing a docker FS tar ball.
>>> I think it was felt that, further support for docker FS was needed.
>>> While there were suggestions of private docker registry, having
>>> something in band (w.r.t openstack) maybe desirable.
>>>
>> [Hongbin Lu] Yes, Glance doesn't support layer of container images which
>> is a missing feature.
>>
>
> Yup, I didn't mean to imply that would do it all for you rather that
> there's been
> some progress there. As far as layered containers goes, you might want to
> look
> into Glare.
>
> Flavio
>
>
> >> * Support enforcing multi-tenancy by doing the following:
>>> >> ** Add configurable options for scheduler to enforce neighboring
>>> >> containers belonging to the same tenant.
>>> >> ** Support hypervisor-based container runtimes.
>>> >>
>>> >> The following topics have been discussed, but the team cannot reach
>>> >> consensus on including them into the short-term project scope. We
>>> >> skipped them for now and might revisit them later.
>>> >> * Support proxying API calls to COEs.
>>> >
>>> > Any link to what this proxy will do and what service it'll talk to?
>>> > I'd generally advice against having proxy calls in services. We've
>>> > just done work in Nova to deprecate the Nova Image proxy.
>>>
>> [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.
>>
>> >
>>> >> * Advanced container operations (i.e. keep container alive, load
>>> >> balancer setup, rolling upgrade).
>>> >> * Nested containers use cases (i.e. provision container hosts).
>>> >> * Container composition (i.e. support docker-compose like DSL).
>>> >>
>>> >> NOTE: I might forgot and mis-understood something. Please feel free
>>> >> to point out if anything is wrong or missing.
>>> >
>>> > It sounds you've got more than enough to work on for now, I think
>>> it's
>>> > fine to table these topics for now.
>>> >
>>> > just my $0.02
>>> > Flavio
>>> >
>>> >
>>> >
>>> >
>>> ______________________________________________________________________
>>> > ____ OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> _______________________________________________________________________
>>> ___
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-
>>> request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> --
> @flaper87
> Flavio Percoco
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160614/000ab124/attachment.html>