<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-2022-jp">
<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:SimSun;}
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:SimSun;}
tt
{mso-style-priority:99;
font-family:SimSun;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:SimSun;}
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">I have an opposing point of view. In summary of below, there are actually three kinds of style.<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. The “python-*client” style. For example:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">$ magnum node-add [--flavor <flavor-id>] <bay><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">2. The OSC style. For example:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">$ openstack bay node add [--flavor <flavor-id>]<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">3. The proposed style (which is a mix of #1 and #2). For example:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">$ magnum bay node add [--flavor <flavor-id>]<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">My observation is that all OpenStack projects are following both #1 and #2. I just couldn't find any OpenStack project that implements #3. If Magnum implements
#3, we immediately become an outlier. I understand the intention is to make the python-client -> OSC migration easier, but the consequence might be more confusion than the original migration plan. Therefore, I would vote against #3.<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""> Ton Ngo [mailto:ton@us.ibm.com]
<br>
<b>Sent:</b> May-16-16 7:10 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [magnum] Discuss the idea of manually managing the bay nodes<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p>I would vote for the OSC pattern to make it easier for the users, since we already expect that migration path.<br>
Also agree with Tom that this is a significant change so we should write a spec to think through carefully.<br>
Ton,<br>
<br>
<img width="16" height="16" id="_x0000_i1025" src="cid:image001.gif@01D1AFC2.3EBC2950" alt="Inactive hide details for Adrian Otto ---05/16/2016 11:24:33 AM---> On May 16, 2016, at 7:59 AM, Steven Dake (stdake) <stdake@c"><span style="color:#424282">Adrian Otto
---05/16/2016 11:24:33 AM---> On May 16, 2016, at 7:59 AM, Steven Dake (stdake) <<a href="mailto:stdake@cisco.com">stdake@cisco.com</a>> wrote: ></span><br>
<br>
<span style="font-size:10.0pt;color:#5F5F5F">From: </span><span style="font-size:10.0pt">Adrian Otto <<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.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">05/16/2016 11:24 AM</span><br>
<span style="font-size:10.0pt;color:#5F5F5F">Subject: </span><span style="font-size:10.0pt">Re: [openstack-dev] [magnum] Discuss the idea of manually managing the bay nodes</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>
<br>
<tt>> On May 16, 2016, at 7:59 AM, Steven Dake (stdake) <<a href="mailto:stdake@cisco.com">stdake@cisco.com</a>> wrote:</tt><br>
<tt>> </tt><br>
<tt>> Tom,</tt><br>
<tt>> </tt><br>
<tt>> Devil's advocate here.. :)</tt><br>
<tt>> </tt><br>
<tt>> Can you offer examples of other OpenStack API services which behave in</tt><br>
<tt>> this way with a API <verb> <object> <object-verb> <options>?</tt><br>
<br>
<tt>The more common pattern is actually:</tt><br>
<br>
<tt><verb> <options> <object> </tt><br>
<br>
<tt>or:</tt><br>
<br>
<tt><verb> <object> <options></tt><br>
<br>
<tt>Examples:</tt><br>
<br>
<tt># trove resize-instance <instance-id> <flavor-id></tt><br>
<tt># nova reboot --hard <instance-id></tt><br>
<br>
<tt>The OSC tool uses:</tt><br>
<br>
<tt><object-name> <verb> <options> <object></tt><br>
<br>
<tt>Example:</tt><br>
<br>
<tt># openstack server reboot [-h] [--hard | --soft] [--wait] <server></tt><br>
<br>
<tt>If we wanted to be consistent with the original Openstack style, the proposal would be something like:</tt><br>
<br>
<tt>magnum reset [--hard] <bay> </tt><br>
<tt>magnum rebuild <bay></tt><br>
<tt>magnum node-delete <bay> </tt><br>
<tt>magnum node-add [--flavor <flavor-id>] <bay> </tt><br>
<tt>magnum node-reset <bay> <name/uuid></tt><br>
<tt>magnum node-list <bay></tt><br>
<br>
<tt>If we wanted to model after OSC, it would be:</tt><br>
<br>
<tt>magnum bay reset [--hard] <bay> </tt><br>
<tt>magnum bay rebuild <bay></tt><br>
<tt>magnum bay node delete <bay> </tt><br>
<tt>magnum bay node add [--flavor <flavor-id>] <bay> </tt><br>
<tt>magnum bay node reset <bay> <name/uuid></tt><br>
<tt>magnum bay node list <bay></tt><br>
<br>
<tt>This one is my preference, because when integrated with OSC, the user does not need to change the command arguments, just swap in “openstack” for “magnum”. The actual order of placement for named options does not matter.</tt><br>
<br>
<tt>Adrian</tt><br>
<br>
<tt>> </tt><br>
<tt>> I'm struggling to think of any off the top of my head, but admittedly</tt><br>
<tt>> don't know all the ins and outs of OpenStack ;)</tt><br>
<tt>> </tt><br>
<tt>> Thanks</tt><br>
<tt>> -steve</tt><br>
<tt>> </tt><br>
<tt>> </tt><br>
<tt>> On 5/16/16, 2:28 AM, "Cammann, Tom" <<a href="mailto:tom.cammann@hpe.com">tom.cammann@hpe.com</a>> wrote:</tt><br>
<tt>> </tt><br>
<tt>>> The discussion at the summit was very positive around this requirement</tt><br>
<tt>>> but as this change will make a large impact to Magnum it will need a spec.</tt><br>
<tt>>> </tt><br>
<tt>>> On the API of things, I was thinking a slightly more generic approach to</tt><br>
<tt>>> incorporate other lifecycle operations into the same API.</tt><br>
<tt>>> Eg:</tt><br>
<tt>>> magnum bay-manage <bay> <life-cycle-op></tt><br>
<tt>>> </tt><br>
<tt>>> magnum bay-manage <bay> reset –hard</tt><br>
<tt>>> magnum bay-manage <bay> rebuild</tt><br>
<tt>>> magnum bay-manage <bay> node-delete <name/uuid></tt><br>
<tt>>> magnum bay-manage <bay> node-add –flavor <flavor></tt><br>
<tt>>> magnum bay-manage <bay> node-reset <name></tt><br>
<tt>>> magnum bay-manage <bay> node-list</tt><br>
<tt>>> </tt><br>
<tt>>> Tom</tt><br>
<tt>>> </tt><br>
<tt>>> From: Yuanying OTSUKA <<a href="mailto:yuanying@oeilvert.org">yuanying@oeilvert.org</a>></tt><br>
<tt>>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"</tt><br>
<tt>>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>></tt><br>
<tt>>> Date: Monday, 16 May 2016 at 01:07</tt><br>
<tt>>> To: "OpenStack Development Mailing List (not for usage questions)"</tt><br>
<tt>>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>></tt><br>
<tt>>> Subject: Re: [openstack-dev] [magnum] Discuss the idea of manually</tt><br>
<tt>>> managing the bay nodes</tt><br>
<tt>>> </tt><br>
<tt>>> Hi,</tt><br>
<tt>>> </tt><br>
<tt>>> I think, user also want to specify the deleting node.</tt><br>
<tt>>> So we should manage “node” individually.</tt><br>
<tt>>> </tt><br>
<tt>>> For example:</tt><br>
<tt>>> $ magnum node-create —bay …</tt><br>
<tt>>> $ magnum node-list —bay</tt><br>
<tt>>> $ magnum node-delete $NODE_UUID</tt><br>
<tt>>> </tt><br>
<tt>>> Anyway, if magnum want to manage a lifecycle of container infrastructure.</tt><br>
<tt>>> This feature is necessary.</tt><br>
<tt>>> </tt><br>
<tt>>> Thanks</tt><br>
<tt>>> -yuanying</tt><br>
<tt>>> </tt><br>
<tt>>> </tt><br>
<tt>>> 2016<span lang="ZH-CN">年</span>5<span lang="ZH-CN">月</span>16<span lang="ZH-CN">日</span>(<span lang="ZH-CN">月</span>) 7:50 Hongbin Lu</tt><br>
<tt>>> <hongbin.lu@huawei.com<<a href="mailto:hongbin.lu@huawei.com">mailto:hongbin.lu@huawei.com</a>>>:</tt><br>
<tt>>> Hi all,</tt><br>
<tt>>> </tt><br>
<tt>>> This is a continued discussion from the design summit. For recap, Magnum</tt><br>
<tt>>> manages bay nodes by using ResourceGroup from Heat. This approach works</tt><br>
<tt>>> but it is infeasible to manage the heterogeneity across bay nodes, which</tt><br>
<tt>>> is a frequently demanded feature. As an example, there is a request to</tt><br>
<tt>>> provision bay nodes across availability zones [1]. There is another</tt><br>
<tt>>> request to provision bay nodes with different set of flavors [2]. For the</tt><br>
<tt>>> request features above, ResourceGroup won’t work very well.</tt><br>
<tt>>> </tt><br>
<tt>>> The proposal is to remove the usage of ResourceGroup and manually create</tt><br>
<tt>>> Heat stack for each bay nodes. For example, for creating a cluster with 2</tt><br>
<tt>>> masters and 3 minions, Magnum is going to manage 6 Heat stacks (instead</tt><br>
<tt>>> of 1 big Heat stack as right now):</tt><br>
<tt>>> * A kube cluster stack that manages the global resources</tt><br>
<tt>>> * Two kube master stacks that manage the two master nodes</tt><br>
<tt>>> * Three kube minion stacks that manage the three minion nodes</tt><br>
<tt>>> </tt><br>
<tt>>> The proposal might require an additional API endpoint to manage nodes or</tt><br>
<tt>>> a group of nodes. For example:</tt><br>
<tt>>> $ magnum nodegroup-create --bay XXX --flavor m1.small --count 2</tt><br>
<tt>>> --availability-zone us-east-1 ….</tt><br>
<tt>>> $ magnum nodegroup-create --bay XXX --flavor m1.medium --count 3</tt><br>
<tt>>> --availability-zone us-east-2 …</tt><br>
<tt>>> </tt><br>
<tt>>> Thoughts?</tt><br>
<tt>>> </tt><br>
<tt>>> [1] </tt><br>
<tt>>> <a href="https://blueprints.launchpad.net/magnum/+spec/magnum-availability-zones">
https://blueprints.launchpad.net/magnum/+spec/magnum-availability-zones</a></tt><br>
<tt>>> [2] <a href="https://blueprints.launchpad.net/magnum/+spec/support-multiple-flavor">
https://blueprints.launchpad.net/magnum/+spec/support-multiple-flavor</a></tt><br>
<tt>>> </tt><br>
<tt>>> Best regards,</tt><br>
<tt>>> Hongbin</tt><br>
<tt>>> __________________________________________________________________________</tt><br>
<tt>>> OpenStack Development Mailing List (not for usage questions)</tt><br>
<tt>>> Unsubscribe: </tt><br>
<tt>>> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<<a href="http://OpenS">http://OpenS</a></tt><br>
<tt>>> <a href="mailto:tack-dev-request@lists.openstack.org?subject:unsubscribe">
tack-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>
<tt>>> __________________________________________________________________________</tt><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>
<tt>> </tt><br>
<tt>> __________________________________________________________________________</tt><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>
<tt>__________________________________________________________________________</tt><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>
<br>
<o:p></o:p></p>
</div>
</div>
</body>
</html>