<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@SimSun";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
tt
{mso-style-priority:99;
font-family:"Courier New";}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-CA" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi Ton,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">magnum container-create –name XXX –image XXX –command XXX<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hongbin<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Ton Ngo [mailto:ton@us.ibm.com]
<br>
<b>Sent:</b> December-10-15 8:18 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] Mesos Conductor using container-create operations<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p>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>
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>
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>
<br>
We should think through the scenarios carefully to come to agreement on how this would work.<br>
<br>
Ton Ngo,<br>
<br>
<br>
<img width="16" height="16" id="_x0000_i1025" src="cid:image001.gif@01D13395.46BB51C0" alt="Inactive hide details for Hongbin Lu ---12/09/2015 03:09:23 PM---As Bharath mentioned, I am +1 to extend the "container" object"><span style="color:#424282">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</span><br>
<br>
<span style="font-size:10.0pt;color:#5F5F5F">From: </span><span style="font-size:10.0pt">Hongbin Lu <<a href="mailto:hongbin.lu@huawei.com">hongbin.lu@huawei.com</a>></span><br>
<span style="font-size:10.0pt;color:#5F5F5F">To: </span><span style="font-size:10.0pt">"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>></span><br>
<span style="font-size:10.0pt;color:#5F5F5F">Date: </span><span style="font-size:10.0pt">12/09/2015 03:09 PM</span><br>
<span style="font-size:10.0pt;color:#5F5F5F">Subject: </span><span style="font-size:10.0pt">Re: [openstack-dev] Mesos Conductor using container-create operations</span><o:p></o:p></p>
<div class="MsoNormal">
<hr size="2" width="100%" noshade="" style="color:#8091A5" align="left">
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<br>
<span style="font-family:"Calibri","sans-serif";color:#1F497D">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.</span><br>
<br>
<span style="font-family:"Calibri","sans-serif";color:#1F497D">Use case:</span><br>
<span style="font-family:"Calibri","sans-serif";color:#1F497D">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.</span><br>
<br>
<span style="font-family:"Calibri","sans-serif";color:#1F497D">Solution:</span><br>
<span style="font-family:"Calibri","sans-serif";color:#1F497D">Implement "container" object for k8s and mesos bay (and all the COEs introduced in the future).</span><br>
<br>
<span style="font-family:"Calibri","sans-serif";color:#1F497D">That's it. I would appreciate if you can share your thoughts on this proposal.</span><br>
<br>
<span style="font-family:"Calibri","sans-serif";color:#1F497D">[1] </span><a href="https://blueprints.launchpad.net/magnum/+spec/unified-containers"><span style="font-family:"Calibri","sans-serif"">https://blueprints.launchpad.net/magnum/+spec/unified-containers</span></a><br>
<br>
<span style="font-family:"Calibri","sans-serif";color:#1F497D">Best regards,</span><br>
<span style="font-family:"Calibri","sans-serif";color:#1F497D">Hongbin</span><br>
<br>
<b><span style="font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-family:"Tahoma","sans-serif""> bharath thiruveedula [<a href="mailto:bharath_ves@hotmail.com">mailto:bharath_ves@hotmail.com</a>]
<b><br>
Sent:</b> December-08-15 11:40 PM<b><br>
To:</b> <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><b><br>
Subject:</b> [openstack-dev] Mesos Conductor using container-create operations</span><br>
<br>
<span style="font-size:13.5pt;font-family:"Calibri","sans-serif"">Hi,</span><br>
<br>
<span style="font-size:13.5pt;font-family:"Calibri","sans-serif"">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.</span><br>
<br>
<span style="font-size:13.5pt;font-family:"Calibri","sans-serif"">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.</span><br>
<br>
<span style="font-size:13.5pt;font-family:"Calibri","sans-serif"">Let me know your suggestions.</span><br>
<br>
<span style="font-size:13.5pt;font-family:"Calibri","sans-serif"">Regards</span><br>
<span style="font-size:13.5pt;font-family:"Calibri","sans-serif"">Bharath T</span><tt><span style="font-size:10.0pt">__________________________________________________________________________</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>OpenStack Development Mailing List (not for usage questions)</tt><br>
<tt>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a></tt><br>
<tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><br>
<br>
</span><o:p></o:p></p>
</div>
</body>
</html>