Open Stack

Hello Hongbin.

See inline comments.

Kind regards,
Denis Makogon

2016-12-07 2:56 GMT+02:00 Hongbin Lu <hongbin.lu at huawei.com>:

> 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.
>

Exactly, i think Pods concept shouldn't appear in Zun (it's all about
Magnum, isn't it?). So, the problem is that K8t Pod is too different from
Docker Swarm node and different from Rkt. Since Zun is aimed to be an
abstraction on-top for different container technologies. So every infra
management should be leveraged to Magnum.

I think it would make more sense to introduce an abstraction, let's say
"Datastore", behind this abstraction we can hide different types of
technologies (required connection attributes, etc.). If i would need to
create container in Swarm i'll use "--datastore swarm.production.com", if i
would need to attach value, i'll ask magnum to do that and whatever i would
need in order to deploy required Zun container.


>
>
>   $ 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.
>
>
>

This is exactly intersection with Magnum. Zun is meant to be
Containers-as-a-Service, but not Containers-infra-management-as-a-Service.
So, if i would need to deploy container on specific Pod i would like to
have capability to deploy it on that pod (no matter if it was deployed by
Magnum or by 3rd-party tools outside of OpenStack), of course there would
be problems with Cinder volumes.

  $ 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?
>
>
>

So, overall, Zun should remain to be agnostic to any container technologies
like Docker, K8t, Rkt, CEO. So every infra management should be leveraged
to Magnum, and Zun should consume container technology CRUD API and use
Magnum in order to modify underlying Nova/Cinder resources.

Another question, why do Zun needs K8t pods CRUD API? Can't Zun talk to
Magnum to work with Magnum?


> [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/20161207/99a8d52a/attachment-0001.html>