<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=iso-8859-1">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<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.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.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 all,<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">According to the decision in the design summit [1], we are going to narrow the scope of the Magnum project [2]. In particular, Magnum will focus on COEs deployment
and management. The efforts of building unified container abstraction will potentially go into a new project. My role here is to collect interests for the new project, help to create a new team (if there are enough interests), and then pass the responsibility
to the new team. An etherpad was created for this purpose:<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"><a href="https://etherpad.openstack.org/p/container-management-service">https://etherpad.openstack.org/p/container-management-service</a><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">If you interest in contributing and/or leveraging the new container service, I would request to have your name and requirements stated in the etherpad. Your
inputs will be appreciated.<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">[1]
<a href="https://etherpad.openstack.org/p/newton-magnum-unified-abstraction">https://etherpad.openstack.org/p/newton-magnum-unified-abstraction</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[2]
<a href="https://review.openstack.org/#/c/311476/">https://review.openstack.org/#/c/311476/</a><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 style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<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""> Adrian Otto [mailto:adrian.otto@rackspace.com]
<br>
<b>Sent:</b> April-23-16 11:27 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Magnum is not a COE installer. It offers multi tenancy from the ground up, is well integrated with OpenStack services, and more COE features pre-configured than you would get with an ordinary stock deployment. For example, magnum offers
integration with keystone that allows developer self-service to get a native container service in a few minutes with the same ease as getting a database server from Trove. It allows cloud operators to set up the COE templates in a way that they can be used
to fit policies of that particular cloud. <o:p></o:p></p>
</div>
<div id="AppleMailSignature">
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div id="AppleMailSignature">
<p class="MsoNormal">Keeping a COE working with OpenStack requires expertise that the Magnum team has codified across multiple options.<br>
<br>
-- <o:p></o:p></p>
<div>
<p class="MsoNormal">Adrian<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
On Apr 23, 2016, at 2:55 PM, Hongbin Lu <<a href="mailto:hongbin.lu@huawei.com">hongbin.lu@huawei.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I am not necessary agree with the viewpoint below, but that is the majority viewpoints when I was trying to sell Magnum to them. There are people who interested
in adopting Magnum, but they ran away after they figured out what Magnum actually offers is a COE deployment service. My takeaway is COE deployment is not the real pain, and there are several alternatives available (Heat, Ansible, Chef, Puppet, Juju, etc.).
Limiting Magnum to be a COE deployment service might prolong the existing adoption problem.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Best regards,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hongbin</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<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""> Georgy Okrokvertskhov [<a href="mailto:gokrokvertskhov@mirantis.com">mailto:gokrokvertskhov@mirantis.com</a>]
<br>
<b>Sent:</b> April-20-16 6:51 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal">If Magnum will be focused on installation and management for COE it will be unclear how much it is different from Heat and other generic orchestrations. It looks like most of the current Magnum functionality is provided by Heat. Magnum
focus on deployment will potentially lead to another Heat-like API. <o:p></o:p></p>
<div>
<p class="MsoNormal">Unless Magnum is really focused on containers its value will be minimal for OpenStack users who already use Heat/Orchestration.<o:p></o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal">On Wed, Apr 20, 2016 at 3:12 PM, Keith Bray <<a href="mailto:keith.bray@rackspace.com" target="_blank">keith.bray@rackspace.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">Magnum doesnıt have to preclude tight integration for single COEs you<br>
speak of. The heavy lifting of tight integration of the COE in to<br>
OpenStack (so that it performs optimally with the infra) can be modular<br>
(where the work is performed by plug-in models to Magnum, not performed by<br>
Magnum itself. The tight integration can be done by leveraging existing<br>
technologies (Heat and/or choose your DevOps tool of choice:<br>
Chef/Ansible/etc). This allows interested community members to focus on<br>
tight integration of whatever COE they want, focusing specifically on the<br>
COE integration part, contributing that integration focus to Magnum via<br>
plug-ins, without having to actually know much about Magnum, but instead<br>
contribute to the COE plug-in using DevOps tools of choice. Pegging<br>
Magnum to one-and-only one COE means there will be a Magnum2, Magnum3,<br>
etc. project for every COE of interest, all with different ways of kicking<br>
off COE management. Magnum could unify that experience for users and<br>
operators, without picking a winner in the COE space ‹ this is just like<br>
Nova not picking a winner between VM flavors or OS types. It just<br>
facilitates instantiation and management of thins. Opinion here: The<br>
value of Magnum is in being a light-weight/thin API, providing modular<br>
choice and plug-ability to COE provisioning and management, thereby<br>
providing operators and users choice of COE instantiation and management<br>
(via the bay concept), where each COE can be as tightly or loosely<br>
integrated as desired by different plug-ins contributed to perform the COE<br>
setup and configurations. So, Magnum could have two or more swarm plug-in<br>
options contributed to the community.. One overlays generic swarm on VMs.<br>
The other swarm plug-in could instantiate swarm tightly integrated to<br>
neutron, keystone, etc on to bare metal. Magnum just facilities a plug-in<br>
model with thin API to offer choice of CEO instantiation and management.<br>
The plug-in does the heavy lifting using whatever methods desired by the<br>
curator.<br>
<br>
Thatıs my $0.2.<br>
<span style="color:#888888"><br>
<span class="hoenzb">-Keith</span></span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
On 4/20/16, 4:49 PM, "Joshua Harlow" <<a href="mailto:harlowja@fastmail.com">harlowja@fastmail.com</a>> wrote:<br>
<br>
>Thierry Carrez wrote:<br>
>> Adrian Otto wrote:<br>
>>> This pursuit is a trap. Magnum should focus on making native container<br>
>>> APIs available. We should not wrap APIs with leaky abstractions. The<br>
>>> lowest common denominator of all COEs is an remarkably low value API<br>
>>> that adds considerable complexity to Magnum that will not<br>
>>> strategically advance OpenStack. If we instead focus our effort on<br>
>>> making the COEs work better on OpenStack, that would be a winning<br>
>>> strategy. Support and compliment our various COE ecosystems.<br>
><br>
>So I'm all for avoiding 'wrap APIs with leaky abstractions' and 'making<br>
>COEs work better on OpenStack' but I do dislike the part about COEs<br>
>(plural) because it is once again the old non-opinionated problem that<br>
>we (as a community) suffer from.<br>
><br>
>Just my 2 cents, but I'd almost rather we pick one COE and integrate<br>
>that deeply/tightly with openstack, and yes if this causes some part of<br>
>the openstack community to be annoyed, meh, to bad. Sadly I have a<br>
>feeling we are hurting ourselves by continuing to try to be everything<br>
>and not picking anything (it's a general thing we, as a group, seem to<br>
>be good at, lol). I mean I get the reason to just support all the<br>
>things, but it feels like we as a community could just pick something,<br>
>work together on figuring out how to pick one, using all these bright<br>
>leaders we have to help make that possible (and yes this might piss some<br>
>people off, to bad). Then work toward making that something great and<br>
>move on...<br>
><br>
>><br>
>> I'm with Adrian on that one. I've attended a lot of container-oriented<br>
>> conferences over the past year and my main takeaway is that this new<br>
>> crowd of potential users is not interested (at all) in an<br>
>> OpenStack-specific lowest common denominator API for COEs. They want to<br>
>> take advantage of the cool features in Kubernetes API or the versatility<br>
>> of Mesos. They want to avoid caring about the infrastructure provider<br>
>> bit (and not deploy Mesos or Kubernetes themselves).<br>
>><br>
>> Let's focus on the infrastructure provider bit -- that is what we do and<br>
>> what the ecosystem wants us to provide.<br>
>><br>
><br>
>__________________________________________________________________________<br>
>OpenStack Development Mailing List (not for usage questions)<br>
>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="color:#999999;background:white">Georgy Okrokvertskhov<br>
Director of Performance Engineering,<br>
</span><span style="font-family:"Arial","sans-serif";color:#999999;background:white">OpenStack Platform Products,</span><span style="color:#999999;background:white"><br>
Mirantis</span><span style="color:#999999"><br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. +1 650 963 9828<br>
Mob. +1 650 996 3284</span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></p>
</div>
</blockquote>
</div>
</div>
</body>
</html>