Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161207/a72fd38c/attachment.html>