<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Dec 12, 2015, at 9:19 AM, Ton Ngo <<a href="mailto:ton@us.ibm.com" class="">ton@us.ibm.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">
<p class="">Hi Hongbin,<br class="">
The proposal sounds reasonable: basically it provides an agnostic alternative to the single command line that a user can invoke with docker or kubectl. If the user needs more advanced support (environment variables, volumes, network, ...), we would defer to
the COE support and the user would need to pick one. <br class="">
</p>
</div>
</div>
</blockquote>
<div>I concur.</div>
<blockquote type="cite" class="">
<div class="">
<div class="">
<p class="">I also notice that the command does not specify a bay. If this is the intention, this could also cover another use case that I hear frequently when talking about Magnum:<br class="">
"I just want to run some containers, I don't want to have to create a bay or figure out what goes into a bay model"<br class="">
In this case, there is probably a default bay model and a default bay that would be created on the first invocation. The command would take some extra time the first time, but afterward it should be fast. The default configuration would come with Magnum, or
be set by the cloud provider. </p>
</div>
</div>
</blockquote>
I like this idea.</div>
<div><br class="">
</div>
<div>Adrian<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="">
<p class="">Ton,<br class="">
<br class="">
<span id="cid:1__=07BBF58ADFC8A3748f9e8a93df938690918c07B@"><graycol.gif></span><font color="#424282" class="">Hongbin Lu ---12/10/2015 08:01:06 PM---Hi Ton, Thanks for the feedback. Here is a clarification. The proposal is neither for using existing</font><br class="">
<br class="">
<font size="2" color="#5F5F5F" class="">From: </font><font size="2" class="">Hongbin Lu <<a href="mailto:hongbin.lu@huawei.com" class="">hongbin.lu@huawei.com</a>></font><br class="">
<font size="2" color="#5F5F5F" class="">To: </font><font size="2" class="">"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" class="">openstack-dev@lists.openstack.org</a>></font><br class="">
<font size="2" color="#5F5F5F" class="">Date: </font><font size="2" class="">12/10/2015 08:01 PM</font><br class="">
<font size="2" color="#5F5F5F" class="">Subject: </font><font size="2" class="">Re: [openstack-dev] Mesos Conductor using container-create operations</font><br class="">
</p>
<hr width="100%" size="2" align="left" noshade="" style="color:#8091A5; " class="">
<br class="">
<br class="">
<br class="">
<font color="#1F497D" face="Calibri" class="">Hi Ton,</font><br class="">
<font color="#1F497D" face="Calibri" class=""></font><br class="">
<font color="#1F497D" face="Calibri" class="">Thanks for the feedback. Here is a clarification. The proposal is neither for using existing DSL to express a container, nor for investing a new DSL. Instead, I proposed to hide the complexity of existing DSLs and
expose a simple API to users. For example, if users want to create a container, they could type something like:</font><br class="">
<font color="#1F497D" face="Calibri" class=""></font><br class="">
<font color="#1F497D" face="Calibri" class="">magnum container-create –name XXX –image XXX –command XXX</font><br class="">
<font color="#1F497D" face="Calibri" class=""></font><br class="">
<font color="#1F497D" face="Calibri" class="">Magnum will process the request and translate it to COE-specific API calls. For k8s, we could dynamically generate a pod with a single container and fill the pod with the inputted values (image, command, etc.).
Similarly, in marathon, we could generate an app based on inputs. A key advantage of that is simple and doesn’t require COE-specific knowledge.</font><br class="">
<font color="#1F497D" face="Calibri" class=""></font><br class="">
<font color="#1F497D" face="Calibri" class="">Best regards,</font><br class="">
<font color="#1F497D" face="Calibri" class="">Hongbin</font><br class="">
<font color="#1F497D" face="Calibri" class=""></font><br class="">
<b class=""><font face="Tahoma" class="">From:</font></b><font face="Tahoma" class=""> Ton Ngo [</font><font face="Tahoma" class=""><a href="mailto:ton@us.ibm.com" class="">mailto:ton@us.ibm.com</a></font><font face="Tahoma" class="">]
</font><b class=""><font face="Tahoma" class=""><br class="">
Sent:</font></b><font face="Tahoma" class=""> December-10-15 8:18 PM</font><b class=""><font face="Tahoma" class=""><br class="">
To:</font></b><font face="Tahoma" class=""> OpenStack Development Mailing List (not for usage questions)</font><b class=""><font face="Tahoma" class=""><br class="">
Subject:</font></b><font face="Tahoma" class=""> Re: [openstack-dev] Mesos Conductor using container-create operations</font><br class="">
<font size="4" face="Times New Roman" class=""></font>
<p class=""><font size="4" face="Times New Roman" class="">I think extending the container object to Mesos via command like container-create is a fine idea. Going into details, however, we run into some complication.<br class="">
1. The user would still have to choose a DSL to express the container. This would have to be a kube and/or swarm DSL since we don't want to invent a new one.<br class="">
2. For Mesos bay in particular, kube or swarm may be running on top of Mesos along side with Marathon, so somewhere along the line, Magnum has to be able to make the distinction and handle things appropriately.<br class="">
<br class="">
We should think through the scenarios carefully to come to agreement on how this would work.<br class="">
<br class="">
Ton Ngo,<br class="">
<br class="">
<br class="">
</font><span id="cid:1__=07BBF58ADFC8A3748f9e8a93df938690918c07B@"><graycol.gif></span><font size="4" color="#424282" face="Times New Roman" class="">Hongbin Lu ---12/09/2015 03:09:23 PM---As Bharath mentioned, I am +1 to extend the "container" object to Mesos
bay. In addition, I propose</font><font size="4" face="Times New Roman" class=""><br class="">
</font><font color="#5F5F5F" face="Times New Roman" class=""><br class="">
From: </font><font face="Times New Roman" class="">Hongbin Lu <</font><a href="mailto:hongbin.lu@huawei.com" class=""><u class=""><font color="#0000FF" face="Times New Roman" class="">hongbin.lu@huawei.com</font></u></a><font face="Times New Roman" class="">></font><font color="#5F5F5F" face="Times New Roman" class=""><br class="">
To: </font><font face="Times New Roman" class="">"OpenStack Development Mailing List (not for usage questions)" <</font><a href="mailto:openstack-dev@lists.openstack.org" class=""><u class=""><font color="#0000FF" face="Times New Roman" class="">openstack-dev@lists.openstack.org</font></u></a><font face="Times New Roman" class="">></font><font color="#5F5F5F" face="Times New Roman" class=""><br class="">
Date: </font><font face="Times New Roman" class="">12/09/2015 03:09 PM</font><font color="#5F5F5F" face="Times New Roman" class=""><br class="">
Subject: </font><font face="Times New Roman" class="">Re: [openstack-dev] Mesos Conductor using container-create operations</font><br class="">
</p>
<hr width="100%" size="2" align="left" noshade="" class="">
<br class="">
<font size="4" face="Times New Roman" class=""><br class="">
<br class="">
</font><font size="4" color="#1F497D" face="Calibri" class=""><br class="">
As Bharath mentioned, I am +1 to extend the “container” object to Mesos bay. In addition, I propose to extend “container” to k8s as well (the details are described in this BP [1]). The goal is to promote this API resource to be technology-agnostic and make
it portable across all COEs. I am going to justify this proposal by a use case.</font><font size="4" face="Times New Roman" class=""><br class="">
</font><font size="4" color="#1F497D" face="Calibri" class=""><br class="">
Use case:<br class="">
I have an app. I used to deploy my app to a VM in OpenStack. Right now, I want to deploy my app to a container. I have basic knowledge of container but not familiar with specific container tech. I want a simple and intuitive API to operate a container (i.e.
CRUD), like how I operated a VM before. I find it hard to learn the DSL introduced by a specific COE (k8s/marathon). Most importantly, I want my deployment to be portable regardless of the choice of cluster management system and/or container runtime. I want
OpenStack to be the only integration point, because I don’t want to be locked-in to specific container tech. I want to avoid the risk that a specific container tech being replaced by another in the future. Optimally, I want Keystone to be the only authentication
system that I need to deal with. I don't want the extra complexity to deal with additional authentication system introduced by specific COE.</font><font size="4" face="Times New Roman" class=""><br class="">
</font><font size="4" color="#1F497D" face="Calibri" class=""><br class="">
Solution:<br class="">
Implement "container" object for k8s and mesos bay (and all the COEs introduced in the future).</font><font size="4" face="Times New Roman" class=""><br class="">
</font><font size="4" color="#1F497D" face="Calibri" class=""><br class="">
That's it. I would appreciate if you can share your thoughts on this proposal.</font><font size="4" face="Times New Roman" class=""><br class="">
</font><font size="4" color="#1F497D" face="Calibri" class=""><br class="">
[1] </font><a href="https://blueprints.launchpad.net/magnum/+spec/unified-containers" class=""><u class=""><font size="4" color="#0000FF" face="Calibri" class="">https://blueprints.launchpad.net/magnum/+spec/unified-containers</font></u></a><font size="4" face="Times New Roman" class=""><br class="">
</font><font size="4" color="#1F497D" face="Calibri" class=""><br class="">
Best regards,<br class="">
Hongbin</font><font size="4" face="Times New Roman" class=""><br class="">
</font><b class=""><font size="4" face="Tahoma" class=""><br class="">
From:</font></b><font size="4" face="Tahoma" class=""> bharath thiruveedula [</font><a href="mailto:bharath_ves@hotmail.com" class=""><u class=""><font size="4" color="#0000FF" face="Tahoma" class="">mailto:bharath_ves@hotmail.com</font></u></a><font size="4" face="Tahoma" class="">]
</font><b class=""><font size="4" face="Tahoma" class=""><br class="">
Sent:</font></b><font size="4" face="Tahoma" class=""> December-08-15 11:40 PM</font><b class=""><font size="4" face="Tahoma" class=""><br class="">
To:</font></b><font size="4" face="Tahoma" class=""> </font><a href="mailto:openstack-dev@lists.openstack.org" class=""><u class=""><font size="4" color="#0000FF" face="Tahoma" class="">openstack-dev@lists.openstack.org</font></u></a><b class=""><font size="4" face="Tahoma" class=""><br class="">
Subject:</font></b><font size="4" face="Tahoma" class=""> [openstack-dev] Mesos Conductor using container-create operations</font><font size="4" face="Times New Roman" class=""><br class="">
</font><font size="5" face="Calibri" class=""><br class="">
Hi,</font><font size="4" face="Times New Roman" class=""><br class="">
</font><font size="5" face="Calibri" class=""><br class="">
As we have discussed in last meeting, we cannot continue with changes in container-create[1] as long as we have suitable use case. But I honestly feel to have some kind of support for mesos + marathon apps, because magnum supports COE related functionalities
for docker swarm (container-create) and k8s (pod-create, rc-create..) but not for mesos bays.</font><font size="4" face="Times New Roman" class=""><br class="">
</font><font size="5" face="Calibri" class=""><br class="">
As hongbin suggested, we use the existing functionality of container-create and support in mesos-conductor. Currently we have container-create only for docker swarm bay. Let's have support for the same command for mesos bay with out any changes in client side.</font><font size="4" face="Times New Roman" class=""><br class="">
</font><font size="5" face="Calibri" class=""><br class="">
Let me know your suggestions.</font><font size="4" face="Times New Roman" class=""><br class="">
</font><font size="5" face="Calibri" class=""><br class="">
Regards<br class="">
Bharath T</font><font face="Courier New" class="">__________________________________________________________________________<br class="">
OpenStack Development Mailing List (not for usage questions)<br class="">
Unsubscribe: </font><a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" class=""><u class=""><font color="#0000FF" face="Courier New" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</font></u></a><u class=""><font color="#0000FF" face="Courier New" class=""><br class="">
</font></u><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class=""><u class=""><font color="#0000FF" face="Courier New" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></u></a><font face="Courier New" class=""><br class="">
</font><tt class="">__________________________________________________________________________<br class="">
OpenStack Development Mailing List (not for usage questions)<br class="">
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">
OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class="">
</tt><tt class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt class=""><br class="">
</tt><br class="">
<br class="">
</div>
__________________________________________________________________________<br class="">
OpenStack Development Mailing List (not for usage questions)<br class="">
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">
OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class="">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</body>
</html>