<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small">Hi Hongbin,<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small"><br>Both of these 2 options have pros and cons :<br><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small">1. If we create our own "pod like concept" in Zun, then:<br>-> It is duplicating the efforts for the features that are already available in a particular COE.<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small">-> It requires huge efforts as compared to second option<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small">-> When we create our own pods then how do we can't say that we are not competing with existing COEs<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small">->
 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<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small"><br><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small">2. If we create proxy for k8s, then:<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small">-> It will be specific to k8s and for other COEs also, we will need to do the same<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small">-> We do not want to compete with any COE and that can be achieved by following this approach<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small">-> Our approach of choosing k8s first might be questionable as in "why to support a specific COE first, why not swarm first" <br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small">-> 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<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small"><br></div>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. </div><div class="gmail_extra">​Also, <div style="font-family:trebuchet ms,sans-serif;font-size:small;display:inline" class="gmail_default">​this design seems quite extensible i.e. <span id="gmail-:5wk" dir="ltr"> we can easily integrate with other COEs without having users to worry which COE they are actually running.</span>Same set of APIs can be used for any COE at the backend​.</div><br><div class="gmail_default" style="font-family:trebuchet ms,sans-serif;font-size:small;display:inline">​For required efforts,we need to think and plan.<br></div><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><font size="2"><span style="font-family:trebuchet ms,sans-serif">Regards<br></span><span style="font-family:trebuchet ms,sans-serif">Shubham</span></font><br></div></div></div></div>
<br><div class="gmail_quote">On Wed, Dec 7, 2016 at 6:26 AM, Hongbin Lu <span dir="ltr"><<a target="_blank" href="mailto:hongbin.lu@huawei.com">hongbin.lu@huawei.com</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">





<div lang="EN-CA">
<div class="gmail-m_7199214292877804673WordSection1">
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Hi all,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">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:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">  $ 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)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">  $ zun create … # this create a k8s pod with one container, or create a sandbox with one container<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">  $ zun k8s pod create … # this create a k8s pod<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">  $ zun docker container create … # this create a docker container<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">  $ zun create … # the behavior of this command is unclear<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">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?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">[1] <a target="_blank" href="https://blueprints.launchpad.net/zun/+spec/k8s-integration">
https://blueprints.launchpad.<wbr>net/zun/+spec/k8s-integration</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Best regards,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Hongbin<u></u><u></u></span></p>
</div>
</div>

<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a target="_blank" rel="noreferrer" href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a target="_blank" rel="noreferrer" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div></div>