Open Stack

Hi Hongbin,

Both of these 2 options have pros and cons :

1. If we create our own "pod like concept" in Zun, then:
-> It is duplicating the efforts for the features that are already
available in a particular COE.
-> It requires huge efforts as compared to second option
-> When we create our own pods then how do we can't say that we are not
competing with existing COEs
-> If we have to provide our own pods and similar features then, we will
need to have some more features (eg: Replication Controller) to attract
users for Zun


2. If we create proxy for k8s, then:
-> It will be specific to k8s and for other COEs also, we will need to do
the same
-> We do not want to compete with any COE and that can be achieved by
following this approach
-> Our approach of choosing k8s first might be questionable as in "why to
support a specific COE first, why not swarm first"
-> Moreover behaving like proxy only doesn't makes much sense. Instead of
using zun, they will use will native clis of respective COE. Zun will just
add complexity for such users

Looking at above, still feel that we should have our own implementation of
pods(or similar term for it) because that's where we should be heading for
Zun. Zun can't be just for CRUD operations of containers. If we take a
common subset of features from each COE and have them in Zun then our goal
is clear that we want to have containers supported inside OpenStack without
the need of any COEs. It sounds like competing with COEs but in fact we are
just trying to make OpenStack friendly for the users/operators who wants to
use containers inside/with OpenStack.
​Also,
​this design seems quite extensible i.e. we can easily integrate with other
COEs without having users to worry which COE they are actually running.Same
set of APIs can be used for any COE at the backend​.

​For required efforts,we need to think and plan.

Regards
Shubham

On Wed, Dec 7, 2016 at 6:26 AM, Hongbin Lu <hongbin.lu at huawei.com> wrote:

> Hi all,
>
>
>
> This is a continued discussion of the k8s integration blueprint [1].
> Currently, Zun exposes a container-oriented APIs that provides service for
> end-users to operate on containers (i.e. CRUD). At the last team meeting,
> we discussed how to introduce k8s to Zun as an alternative to the Docker
> driver. There are two approaches that has been discussed:
>
>
>
> 1. Introduce the concept of Pod. If we go with this approach, an API
> endpoint (i.e. /pods) will be added to the Zun APIs. Both Docker driver and
> k8s driver need to implement this endpoint. In addition, all the future
> drivers need to implement this endpoint as well (or throw a NotImplemented
> exception). Some of our team members raised concerns about this approach.
> The main concern is that this approach will hide a lot of k8s-specific
> features (i.e. replication controller) or there will be a lot of work to
> bring all those features to Zun.
>
>
>
>   $ zun pod-create … # this create a k8s pod (if k8s driver is used), or
> create a sandbox with a set of containers (if docker driver is used)
>
>   $ zun create … # this create a k8s pod with one container, or create a
> sandbox with one container
>
>
>
> 2. Introduce a dedicated k8s endpoint that acts as a proxy to k8s APIs.
> This will expose all the k8s features but users won’t have a unified APIs
> across drivers.
>
>
>
>   $ zun k8s pod create … # this create a k8s pod
>
>   $ zun docker container create … # this create a docker container
>
>   $ zun create … # the behavior of this command is unclear
>
>
>
> So far, we haven’t decided which approach to use (or use a third
> approach), but we wanted to collect more feedback before making a decision.
> Thoughts?
>
>
>
> [1] https://blueprints.launchpad.net/zun/+spec/k8s-integration
>
>
>
> Best regards,
>
> Hongbin
>
> __________________________________________________________________________
> 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/20161212/0fd087cb/attachment.html>