<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:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"MS Gothic";
panose-1:2 11 6 9 7 2 5 8 2 4;}
@font-face
{font-family:MingLiU;
panose-1:2 2 5 9 0 0 0 0 0 0;}
@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:"\@MingLiU";
panose-1:2 2 5 9 0 0 0 0 0 0;}
@font-face
{font-family:"\@MS Gothic";
panose-1:2 11 6 9 7 2 5 8 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
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;
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle25
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.string1
{mso-style-name:string1;
color:#004080;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:619144547;
mso-list-type:hybrid;
mso-list-template-ids:-1808522574 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;}
@list l1
{mso-list-id:1336495973;
mso-list-type:hybrid;
mso-list-template-ids:1320853790 -1320403494 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-start-at:2;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;
font-family:Symbol;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Youcef,
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Awesome work! This is all very excellent and a major contribution to the Quantum LBaaS effort. Without a well defined data model and API, nothing else can happen.<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">I do have a few comments & questions which perhaps some have already been made.<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">Peter Mellquist<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hewlett Packard Company<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="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">1)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">API Schemas<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">What are your thoughts about schemas?
<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Do we envision any schemas do define the request / response bodies e.g. JSON schema?
<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">We require some way to define JSON payloads OR is the Wiki the definitive source? ( e.g. in Atlas you had XSDs )<o:p></o:p></span></p>
<p class="MsoListParagraph"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">2)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Keystone integration<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I think we should call out Keystone 2.0 as the version to be integrated with at this point.
<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">We should mention the AuthZ rules for tenant access including the default using the token resolved tenantId and Quantum 2 style.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">‘</span><span lang="EN" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The default authorization settings allow only administrative
users to create resources on behalf of a different tenant.’ Not sure what you mean here?</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">3)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Pagination<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">All GET’s which can return lengthy lists should support a pagination technique as the ‘limit and marker’ method use in other OS APIs.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">4)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Bulk Operations<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">‘Bulk operations are always performed atomically, meaning that either all or none of the objects in the request body are created.’</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Does this imply that partial failures on the service are ‘unwound’ or rolled back? This seems complex.</span><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"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">5)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">API extensions<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The assumption is that we will use the exact same API extension framework devised in Nova including how extensions are advertised and integrated.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Does this imply XSDs?<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="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">6)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Limits<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">How are things like /limits handled as you had in Atlas ( max LBs, max lengths, max members, etc )<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="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">7)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Data Model<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">From a modeling perspective I see that VIP has a ‘lb_method’. I see this more as an attribute of the logical LB and not part of the virtual IP.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Can this instead become only an attribute of the Pool?<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="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">8)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">204 on Deletes<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Deletes commonly return 204 status within OS APIs.<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="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">9)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">/stats<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I think that a /stats call should be allowed to return lazy stats where this is not real time. If so, we should mention it as perhaps delayed up to
N minutes.<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="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">10)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> Dangling references<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Since you have modeled VIPs, members and health monitors as their own collections, how do we handle cases where something is deleted but still referenced
by a pool? <o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Do we prohibit the delete until all references are also deleted?<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Do we put the pool in an invalid state?<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"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in"><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"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><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"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Youcef Laribi [mailto:Youcef.Laribi@eu.citrix.com]
<br>
<b>Sent:</b> Friday, October 26, 2012 8:03 PM<br>
<b>To:</b> Sachin Thakkar; Serge Maskalik; Eugene Nikanorov; Ilya Shakhat; Samuel Bercovici; Rudra Rugge; Alex Gosse; Leon Cui; Brent Busby; Kobi Samoray; Anand Palanisamy; John Gruber; Chinmay Naik; Oleg Bondarev; Eugene Kirpichev; Roman Alekseenkov; Salvatore
Orlando; Mellquist, Peter; Dan Wendlandt; OpenStack Development Mailing List (openstack-dev@lists.openstack.org)<br>
<b>Subject:</b> [openstack-dev][Quantum][LBaaS] LBaaS API 1.0 spec draft<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I have put a first draft of the LBaaS API on the wiki page <a href="http://wiki.openstack.org/Quantum/LBaaS/API_1.0">http://wiki.openstack.org/Quantum/LBaaS/API_1.0</a>,
so please have a look before next week’s meeting. There is still some work to be done on it, but the essential details to start the implementation should be there.<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,<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Youcef</span></a><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"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Youcef Laribi
<br>
<b>Sent:</b> Friday, October 26, 2012 10:16 AM<br>
<b>To:</b> 'Sachin Thakkar'<br>
<b>Cc:</b> Eugene Nikanorov; Ilya Shakhat; Samuel Bercovici; Rudra Rugge; Alex Gosse; Leon Cui; Brent Busby; Kobi Samoray; Anand Palanisamy; John Gruber; Chinmay Naik; Oleg Bondarev; Eugene Kirpichev; Roman Alekseenkov; Salvatore Orlando; Peter Mellquist; Dan
Wendlandt; Serge Maskalik<br>
<b>Subject:</b> RE: Specifying Tenant-ID in REST API URLs<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks Sachin for filing a blueprint for this!<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 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Sachin Thakkar [<a href="mailto:sthakkar@vmware.com">mailto:sthakkar@vmware.com</a>]
<br>
<b>Sent:</b> Friday, October 26, 2012 10:06 AM<br>
<b>To:</b> Youcef Laribi<br>
<b>Cc:</b> Eugene Nikanorov; Ilya Shakhat; Samuel Bercovici; Rudra Rugge; Alex Gosse; Leon Cui; Brent Busby; Kobi Samoray; Anand Palanisamy; John Gruber; Chinmay Naik; Oleg Bondarev; Eugene Kirpichev; Roman Alekseenkov; Salvatore Orlando; Peter Mellquist; Dan
Wendlandt; Serge Maskalik<br>
<b>Subject:</b> Re: Specifying Tenant-ID in REST API URLs<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:black">Excellent, thanks Youcef. I've filed this blueprint for tracking purposes - <a href="https://blueprints.launchpad.net/quantum/+spec/lbaas-restapi-tenant">https://blueprints.launchpad.net/quantum/+spec/lbaas-restapi-tenant</a><o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:black">When we're ready we can formalize the wiki link, object model etc and fill in the specification section. For now, I've simply pointed to the etherpad from the summit.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:black">All, please feel free to join the bp.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:black">Thanks,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-family:"Arial","sans-serif";color:black">Sachin<o:p></o:p></span></p>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-family:"Arial","sans-serif";color:black">
<hr size="2" width="100%" align="center">
</span></div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-family:"Helvetica","sans-serif";color:black">From:
</span></b><span style="font-family:"Helvetica","sans-serif";color:black">"Youcef Laribi" <<a href="mailto:Youcef.Laribi@eu.citrix.com">Youcef.Laribi@eu.citrix.com</a>><br>
<b>To: </b>"Serge Maskalik" <<a href="mailto:smaskalik@vmware.com">smaskalik@vmware.com</a>><br>
<b>Cc: </b>"Eugene Nikanorov" <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>>, "Ilya Shakhat" <<a href="mailto:ishakhat@mirantis.com">ishakhat@mirantis.com</a>>, "Samuel Bercovici" <<a href="mailto:SamuelB@radware.com">SamuelB@radware.com</a>>,
"Rudra Rugge" <<a href="mailto:rrugge@vmware.com">rrugge@vmware.com</a>>, "Alex Gosse" <<a href="mailto:Alex.Gosse@riverbed.com">Alex.Gosse@riverbed.com</a>>, "Leon Cui" <<a href="mailto:lcui@vmware.com">lcui@vmware.com</a>>, "Brent Busby" <<a href="mailto:bbusby@ebay.com">bbusby@ebay.com</a>>,
"Kobi Samoray" <<a href="mailto:KobiS@radware.com">KobiS@radware.com</a>>, "Anand Palanisamy" <<a href="mailto:apalanisamy@paypal.com">apalanisamy@paypal.com</a>>, "John Gruber" <<a href="mailto:J.Gruber@f5.com">J.Gruber@f5.com</a>>, "Chinmay Naik" <<a href="mailto:cnaik@paypal.com">cnaik@paypal.com</a>>,
"Oleg Bondarev" <<a href="mailto:obondarev@mirantis.com">obondarev@mirantis.com</a>>, "Eugene Kirpichev" <<a href="mailto:ekirpichev@mirantis.com">ekirpichev@mirantis.com</a>>, "Roman Alekseenkov" <<a href="mailto:ralekseenkov@mirantis.com">ralekseenkov@mirantis.com</a>>,
"Salvatore Orlando" <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>>, "Peter Mellquist" <<a href="mailto:peter.mellquist@hp.com">peter.mellquist@hp.com</a>>, "Sachin Thakkar" <<a href="mailto:sthakkar@vmware.com">sthakkar@vmware.com</a>>, "Dan
Wendlandt" <<a href="mailto:dan@nicira.com">dan@nicira.com</a>><br>
<b>Sent: </b>Friday, October 26, 2012 9:55:13 AM<br>
<b>Subject: </b>RE: Specifying Tenant-ID in REST API URLs<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Serge,</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I’m in the process of putting together the API spec by merging your API doc with mine, and following Quantum API style and naming conventions. Should be able
to share something by the end of today.</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Youcef</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black"> Serge Maskalik [<a href="mailto:smaskalik@vmware.com">mailto:smaskalik@vmware.com</a>]
<br>
<b>Sent:</b> Thursday, October 25, 2012 10:15 PM<br>
<b>To:</b> Youcef Laribi; Dan Wendlandt; Eugene Nikanorov; Ilya Shakhat; Samuel Bercovici; Rudra Rugge; Alex Gosse; Leon Cui; Brent Busby; Kobi Samoray; Anand Palanisamy; John Gruber; Chinmay Naik; Oleg Bondarev; Eugene Kirpichev; Roman Alekseenkov; Salvatore
Orlando; Peter Mellquist; Sachin Thakkar<br>
<b>Subject:</b> Re: Specifying Tenant-ID in REST API URLs</span><span style="color:black"><o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-family:"Arial","sans-serif";color:black">Folks,
<br>
<br>
I just wanted to get a sense on activity for next week's sync-up. Do we have the Blueprints started? If so, can folks respond with active Blueprint URLs.
<br>
<br>
Youcef - how are the API definition going? Can you point to the latest, if possible? Thanks in advance.
<br>
<br>
-Serge</span><span style="color:black"><o:p></o:p></span></p>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-family:"Arial","sans-serif";color:black">
<hr size="2" width="100%" align="center">
</span></div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-family:"Helvetica","sans-serif";color:black">From:
</span></b><span style="font-family:"Helvetica","sans-serif";color:black">"Youcef Laribi" <<a href="mailto:Youcef.Laribi@eu.citrix.com" target="_blank">Youcef.Laribi@eu.citrix.com</a>><br>
<b>To: </b>"Salvatore Orlando" <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>>, "Peter Mellquist" <<a href="mailto:peter.mellquist@hp.com" target="_blank">peter.mellquist@hp.com</a>><br>
<b>Cc: </b>"Dan Wendlandt" <<a href="mailto:dan@nicira.com" target="_blank">dan@nicira.com</a>>, "Eugene Nikanorov" <<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>>, "Ilya Shakhat" <<a href="mailto:ishakhat@mirantis.com" target="_blank">ishakhat@mirantis.com</a>>,
"Leon Cui" <<a href="mailto:lcui@vmware.com" target="_blank">lcui@vmware.com</a>>, "Brent Busby" <<a href="mailto:bbusby@ebay.com" target="_blank">bbusby@ebay.com</a>>, "Kobi Samoray" <<a href="mailto:KobiS@radware.com" target="_blank">KobiS@radware.com</a>>,
"Anand Palanisamy" <<a href="mailto:apalanisamy@paypal.com" target="_blank">apalanisamy@paypal.com</a>>, "John Gruber" <<a href="mailto:J.Gruber@f5.com" target="_blank">J.Gruber@f5.com</a>>, "Samuel Bercovici" <<a href="mailto:SamuelB@radware.com" target="_blank">SamuelB@radware.com</a>>,
"Rudra Rugge" <<a href="mailto:rrugge@vmware.com" target="_blank">rrugge@vmware.com</a>>, "Alex Gosse" <<a href="mailto:Alex.Gosse@riverbed.com" target="_blank">Alex.Gosse@riverbed.com</a>>, "Serge Maskalik" <<a href="mailto:smaskalik@vmware.com" target="_blank">smaskalik@vmware.com</a>>,
"Chinmay Naik" <<a href="mailto:cnaik@paypal.com" target="_blank">cnaik@paypal.com</a>>, "Oleg Bondarev" <<a href="mailto:obondarev@mirantis.com" target="_blank">obondarev@mirantis.com</a>>, "Eugene Kirpichev" <<a href="mailto:ekirpichev@mirantis.com" target="_blank">ekirpichev@mirantis.com</a>>,
"Roman Alekseenkov" <<a href="mailto:ralekseenkov@mirantis.com" target="_blank">ralekseenkov@mirantis.com</a>><br>
<b>Sent: </b>Thursday, October 25, 2012 4:45:46 PM<br>
<b>Subject: </b>RE: Specifying Tenant-ID in REST API URLs</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks Salvatore.</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">So Peter, an admin role should be able to access any tenant’s resources by simply using the query string filtering mechanism of the API:</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Courier New";color:black">GET /v2.0/vips?tenant_id=</span><span style="font-family:"Courier New";color:red">100</span><span style="color:red">
</span><span style="color:black">(with keystone auth middleware returning tenant_id=</span><span style="color:red">456</span><span style="color:black">, role=</span><span style="color:red">admin</span><span style="color:black">)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">This should return the vips of tenant_id 100 even though the caller is actually tenant 456 (who has an admin role). If tenant 456 wasn’t an admin, I suspect
he would get an “empty” result, rather than the usual “401 Unauthorized” error (that would be the only slight downside to this).</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Are we then comfortable with removing the tenant_id from the URLs?</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Youcef</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:black"> Salvatore Orlando [<a href="mailto:sorlando@nicira.com" target="_blank">mailto:sorlando@nicira.com</a>]
<br>
<b>Sent:</b> Thursday, October 25, 2012 4:22 PM<br>
<b>To:</b> Youcef Laribi<br>
<b>Cc:</b> Dan Wendlandt; Mellquist, Peter; Eugene Nikanorov; Ilya Shakhat; Leon Cui; Busby, Brent; Kobi Samoray; Palanisamy, Anand; John Gruber; Samuel Bercovici; Rudra Rugge; Alex Gosse; Serge Maskalik; Naik, Chinmay; Oleg Bondarev; Eugene Kirpichev; Roman
Alekseenkov<br>
<b>Subject:</b> Re: Specifying Tenant-ID in REST API URLs</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">Yes it is correct.<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:black">The default behaviour is that each tenant will get its own object only, unless it is an administrator, in which case it will get all objects.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">This behaviour is actually not enforced by the policy engine, but hardcoded in the db management logic.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">The policy engine however regulates details such as "shared" and "external" networks. What you find in policy.json is a default set of policies that you can customize according to your needs; for instance you can
specify more roles.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Policy.json also controls who can perform some operations; as an example the creation of "shared" and "external" networks is reserved to admins only by default, but you can allow any tenant, or a specific group
of tenants, to perform this operations, just by editing the file (you won't even need to restart Quantum).<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Salvatore<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:black">On 26 October 2012 00:16, Youcef Laribi <<a href="mailto:Youcef.Laribi@eu.citrix.com" target="_blank">Youcef.Laribi@eu.citrix.com</a>> wrote:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:black">So if I understood the code correctly, in Quantum, there are 2 basic roles:<br>
<br>
1. Admin<br>
2. Normal<br>
<br>
If the user making the request has an "admin" role (according to the keystone token in the request header), then when he issues a Quantum API request like:<br>
<br>
GET /v2.0/networks<br>
<br>
He will get all the networks of all the tenants.<br>
<br>
If however, the user doesn't have an "admin" role (normal user), then he will get only his own networks for the same call (the result is filtered).<br>
<br>
Is my understanding correct?<br>
</span><span style="color:#888888"><br>
<span class="hoenzb">Youcef</span></span><span style="color:black"><o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="color:black"><br>
<br>
-----Original Message-----<br>
From: Dan Wendlandt [mailto:<a href="mailto:dan@nicira.com" target="_blank">dan@nicira.com</a>]<br>
Sent: Thursday, October 25, 2012 3:38 PM<br>
To: Youcef Laribi<br>
Cc: Mellquist, Peter; Eugene Nikanorov; Ilya Shakhat; Leon Cui; Busby, Brent; Kobi Samoray; Palanisamy, Anand; John Gruber; Samuel Bercovici; Rudra Rugge; Alex Gosse; Serge Maskalik; Naik, Chinmay; Salvatore Orlando; Oleg Bondarev; Eugene Kirpichev; Roman Alekseenkov<br>
Subject: Re: Specifying Tenant-ID in REST API URLs<br>
<br>
On Thu, Oct 25, 2012 at 3:25 PM, Youcef Laribi <<a href="mailto:Youcef.Laribi@eu.citrix.com" target="_blank">Youcef.Laribi@eu.citrix.com</a>> wrote:<br>
> Yes, they would be. For the sake of consistency I prefer the LBaaS<br>
> APIs to use a same style and conventions as the Quantum APIs if<br>
> possible. So, I’m waiting to hear clarifications from Dan or Salvatore<br>
> on how authorization is handled in Quantum without the tenant-id being in the URL.<br>
<br>
Here's the standard auth.py code that grabs keystone info from the headers and puts it in the context object:<br>
<br>
<a href="https://github.com/openstack/quantum/blob/master/quantum/auth.py" target="_blank">https://github.com/openstack/quantum/blob/master/quantum/auth.py</a><br>
<br>
This is then returned whenever the context of a request is asked for:<br>
<br>
<a href="https://github.com/openstack/quantum/blob/master/quantum/api/v2/resource.py#L43" target="_blank">https://github.com/openstack/quantum/blob/master/quantum/api/v2/resource.py#L43</a><br>
<br>
This context object is then used in validation methods in <a href="https://github.com/openstack/quantum/blob/master/quantum/api/v2/base.py" target="_blank">
https://github.com/openstack/quantum/blob/master/quantum/api/v2/base.py</a><br>
as well as passed to all plugin methods:<br>
<br>
<a href="https://github.com/openstack/quantum/blob/master/quantum/quantum_plugin_base_v2.py" target="_blank">https://github.com/openstack/quantum/blob/master/quantum/quantum_plugin_base_v2.py</a><br>
<br>
Dan<br>
<br>
<br>
><br>
><br>
><br>
> Youcef<br>
><br>
><br>
><br>
> From: Mellquist, Peter [mailto:<a href="mailto:peter.mellquist@hp.com" target="_blank">peter.mellquist@hp.com</a>]<br>
> Sent: Thursday, October 25, 2012 3:17 PM<br>
><br>
><br>
> To: Youcef Laribi; Eugene Nikanorov<br>
> Cc: Ilya Shakhat; Leon Cui; Busby, Brent; Kobi Samoray; Dan Wendlandt;<br>
> Palanisamy, Anand; John Gruber; Samuel Bercovici; Rudra Rugge; Alex<br>
> Gosse; Serge Maskalik; Naik, Chinmay; Salvatore Orlando; Oleg<br>
> Bondarev; Eugene Kirpichev; Roman Alekseenkov<br>
> Subject: RE: Specifying Tenant-ID in REST API URLs<br>
><br>
><br>
><br>
> Yes this is the question.<br>
><br>
><br>
><br>
> I am assuming our data model will have resources contained by tenants<br>
> like you did within Atlas and is common across Openstack.<br>
><br>
><br>
><br>
> Peter.<br>
><br>
><br>
><br>
> From: Youcef Laribi [mailto:<a href="mailto:Youcef.Laribi@eu.citrix.com" target="_blank">Youcef.Laribi@eu.citrix.com</a>]<br>
> Sent: Thursday, October 25, 2012 2:47 PM<br>
> To: Mellquist, Peter; Eugene Nikanorov<br>
> Cc: Ilya Shakhat; Leon Cui; Busby, Brent; Kobi Samoray; Dan Wendlandt;<br>
> Palanisamy, Anand; John Gruber; Samuel Bercovici; Rudra Rugge; Alex<br>
> Gosse; Serge Maskalik; Naik, Chinmay; Salvatore Orlando; Oleg<br>
> Bondarev; Eugene Kirpichev; Roman Alekseenkov<br>
> Subject: RE: Specifying Tenant-ID in REST API URLs<br>
><br>
><br>
><br>
> Peter,<br>
><br>
><br>
><br>
> Agree. Hence my earlier question to the Quantum people of how they<br>
> handle Authorization with the absence of “tenant-id” from the URL for<br>
> your exact scenario (e.g. admin role finding out the networks of tenant A).<br>
><br>
><br>
><br>
> Youcef<br>
><br>
><br>
><br>
> From: Mellquist, Peter [mailto:<a href="mailto:peter.mellquist@hp.com" target="_blank">peter.mellquist@hp.com</a>]<br>
> Sent: Thursday, October 25, 2012 2:41 PM<br>
> To: Youcef Laribi; Eugene Nikanorov<br>
> Cc: Ilya Shakhat; Leon Cui; Busby, Brent; Kobi Samoray; Dan Wendlandt;<br>
> Palanisamy, Anand; John Gruber; Samuel Bercovici; Rudra Rugge; Alex<br>
> Gosse; Serge Maskalik; Naik, Chinmay; Salvatore Orlando; Oleg<br>
> Bondarev; Eugene Kirpichev; Roman Alekseenkov<br>
> Subject: RE: Specifying Tenant-ID in REST API URLs<br>
><br>
><br>
><br>
> Hi,<br>
><br>
><br>
><br>
> My point was only to ensure we allow a way to achieve cross tenant<br>
> access for an admin role. Normally, the Keystone tenantId must match<br>
> the tenantId in the resource being accessed but for admin roles the<br>
> keystone tenantId has scope to access all tenants. For example in the<br>
> Atlas style, for logical load balancers which are owned by the tenant<br>
> they are not shared unless you have special authorization, like an administrator.<br>
><br>
><br>
><br>
> Examples:<br>
><br>
> GET /v2/100/loadbalancers ( with keystone auth middleware returning<br>
> tenantId=100 )<br>
><br>
> This would be authorized , 100 can access 100’s resources<br>
><br>
><br>
><br>
> GET /v2/101/loadbalancers ( with keystone auth middleware returning<br>
> tenantId=100 )<br>
><br>
> Not authorized, 100 cannot access 101’s resources<br>
><br>
><br>
><br>
> GET /v2/100/loadbalancers ( with keystone auth middleware returning<br>
> tenantId=200 , role = admin)<br>
><br>
> Authorized, 200 is admin<br>
><br>
><br>
><br>
> If you drop the tenantId in the URI you have..<br>
><br>
> GET /V2/loadbalancers ( with keystone auth middleware returning<br>
> tenantId=100 , so you can only access 100’s resources)<br>
><br>
> If I am the admin and I need to access a tenants LBs how is this done?<br>
><br>
><br>
><br>
> Here is a good paper on the topic :<br>
><br>
> <a href="https://github.com/RackerWilliams/multi-tenant-accounting/blob/master/" target="_blank">
https://github.com/RackerWilliams/multi-tenant-accounting/blob/master/</a><br>
> tenants.pdf?raw=true<br>
><br>
><br>
><br>
><br>
><br>
> Peter.<br>
><br>
><br>
><br>
><br>
><br>
> From: Youcef Laribi [mailto:<a href="mailto:Youcef.Laribi@eu.citrix.com" target="_blank">Youcef.Laribi@eu.citrix.com</a>]<br>
> Sent: Thursday, October 25, 2012 11:42 AM<br>
> To: Eugene Nikanorov; Mellquist, Peter<br>
> Cc: Ilya Shakhat; Leon Cui; Busby, Brent; Kobi Samoray; Dan Wendlandt;<br>
> Palanisamy, Anand; John Gruber; Samuel Bercovici; Rudra Rugge; Alex<br>
> Gosse; Serge Maskalik; Naik, Chinmay; Salvatore Orlando; Oleg<br>
> Bondarev; Eugene Kirpichev; Roman Alekseenkov<br>
> Subject: RE: Specifying Tenant-ID in REST API URLs<br>
><br>
><br>
><br>
> Peter, Eugene,<br>
><br>
><br>
><br>
> Changing to the subject to a more appropriate title.<br>
><br>
><br>
><br>
> Just for information, Quantum changed its API style between 1.0<br>
> version (which had tenant-id in the URL, like the rest of OpenStack<br>
> APIs) and the<br>
> 2.0 version (which doesn’t):<br>
><br>
><br>
><br>
> Quantum API 1.0:<br>
> <a href="http://docs.openstack.org/api/openstack-network/1.0/content/index.html" target="_blank">
http://docs.openstack.org/api/openstack-network/1.0/content/index.html</a><br>
><br>
> Quantum API 2.0:<br>
> <a href="http://docs.openstack.org/api/openstack-network/2.0/content/index.html" target="_blank">
http://docs.openstack.org/api/openstack-network/2.0/content/index.html</a><br>
><br>
><br>
><br>
> Can somebody from the Quantum team (Dan or Salvatore) explain the<br>
> reasoning behind the change and how is Authorization handled in 2.0 vs. 1.0?<br>
><br>
><br>
><br>
> Thanks<br>
><br>
> Youcef<br>
><br>
><br>
><br>
> From: Eugene Nikanorov [mailto:<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>]<br>
> Sent: Thursday, October 25, 2012 10:52 AM<br>
> To: Mellquist, Peter<br>
> Cc: Ilya Shakhat; Leon Cui; Youcef Laribi; Busby, Brent; Kobi Samoray;<br>
> Dan Wendlandt; Palanisamy, Anand; John Gruber; Samuel Bercovici; Rudra<br>
> Rugge; Alex Gosse; Serge Maskalik; Naik, Chinmay; Salvatore Orlando;<br>
> Oleg Bondarev; Eugene Kirpichev; Roman Alekseenkov<br>
> Subject: Re: </span><span style="font-family:"MS Gothic";color:black">答复</span><span style="color:black">: Questions to REST API proposal<br>
><br>
><br>
><br>
> Hi Peter,<br>
><br>
><br>
><br>
>> With Keystone middleware the requestors tenantId is injected in the<br>
>> headers of the request, so the API server can see the tenant of the<br>
>> client making the request.<br>
><br>
> That's correct. That will be used to make authorization decision<br>
> (whether tenant can access the resource)<br>
><br>
><br>
><br>
>> For example, If I am the admin of the LB then my tenant may have<br>
>> access to all LBs.<br>
><br>
> I think we want it in a bit different way: LBs as a devices may be<br>
> shared<br>
> (hardware) or private (VMs).<br>
><br>
> LB (VIP, In our new API terminology) deployed on hardware device<br>
> should be accessed only from the tenant that have deployed it. VIP<br>
> deployed on the shared device are visible to provider, but tenant sees<br>
> only those VIPs that it has deployed.<br>
><br>
> If tenant creates it's own private device (by launching VM with, say,<br>
> HAProxy), other tenants can't deploy VIPs on that device and can't see<br>
> neither device itself nor VIP deployed on it.<br>
><br>
><br>
><br>
> Are there reasons to make lbaas API in different style from the Core<br>
> Quantum API v2.0?<br>
><br>
><br>
><br>
> Thanks,<br>
><br>
> Eugene.<br>
><br>
> On Thu, Oct 25, 2012 at 8:45 PM, Mellquist, Peter<br>
> <<a href="mailto:peter.mellquist@hp.com" target="_blank">peter.mellquist@hp.com</a>><br>
> wrote:<br>
><br>
> Hi Eugene,<br>
><br>
><br>
><br>
> With Keystone middleware the requestors tenantId is injected in the<br>
> headers of the request, so the API server can see the tenant of the<br>
> client making the request. The middleware resolves a token or signed<br>
> request to this tenant. Getting rid of the tenantId from the URI will<br>
> not allow cross tenant access. For example, If I am the admin of the<br>
> LB then my tenant may have access to all LBs. Also, most all of the<br>
> other OS APIs have tenant in the URI as resources are organized by tenant.<br>
><br>
><br>
><br>
> Peter.<br>
><br>
><br>
><br>
> From: Eugene Nikanorov [mailto:<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>]<br>
> Sent: Thursday, October 25, 2012 3:38 AM<br>
> To: Ilya Shakhat<br>
> Cc: Leon Cui; Youcef Laribi; Busby, Brent; Kobi Samoray; Dan<br>
> Wendlandt; Palanisamy, Anand; John Gruber; Mellquist, Peter; Samuel<br>
> Bercovici; Rudra Rugge; Alex Gosse; Serge Maskalik; Naik, Chinmay;<br>
> Salvatore Orlando; Oleg Bondarev; Eugene Kirpichev; Roman Alekseenkov<br>
> Subject: Re: </span><span style="font-family:"MS Gothic";color:black">答复</span><span style="color:black">: Questions to REST API proposal<br>
><br>
><br>
><br>
> Folks,<br>
><br>
><br>
><br>
> I suggest we stick with v2.0 style of calls, where there is no /tenants/XYZ.<br>
><br>
> Our current vision is that API calls should look like following:<br>
><br>
><br>
><br>
> /v2.0/balancer/lbaas/vips.json?param1=value1¶m2=value2<br>
><br>
> /v2.0/balancer/lbaas/vips/{vip_id}.json?param1=value1¶m2=value2<br>
><br>
><br>
><br>
> where:<br>
><br>
> - balancer - type of advanced service within quantum<br>
><br>
> - lbaas - particular implementation of service "balancer"<br>
><br>
> - flat resource API, like in quantum API v2.0<br>
><br>
><br>
><br>
> Additional parameters like tenant_id, lb id, etc, are provided in<br>
> parameters.<br>
><br>
> If we're talking about id of resource being accessed, that it is<br>
> provided in url, just like in current quantum API, e.g.<br>
><br>
><br>
><br>
> .../vips/{vip_id}.json?... - for operations on particular vip.<br>
><br>
><br>
><br>
> Thanks,<br>
><br>
> Eugene.<br>
><br>
> On Thu, Oct 25, 2012 at 2:20 PM, Ilya Shakhat <<a href="mailto:ishakhat@mirantis.com" target="_blank">ishakhat@mirantis.com</a>> wrote:<br>
><br>
> One point for flat URL structure is simplicity of search operations.<br>
> The use<br>
> case:<br>
><br>
> * tenant have a large number of back-end servers deployed on several<br>
> load-balancers;<br>
><br>
> * there is a monitoring system that reports only host-name of<br>
> back-end;<br>
><br>
> * users needs to put back-end server out of service.<br>
><br>
> In case of flat addressing, user can find backend id by query like<br>
> this: GET /lbaas/v1.0/tenants/1000/members?name=backendname<br>
><br>
> But if addressing is hierarchical, then he needs to iterate all pools.<br>
><br>
><br>
><br>
> Thanks,<br>
><br>
> Ilya<br>
><br>
><br>
><br>
> 2012/10/25 Leon Cui <<a href="mailto:lcui@vmware.com" target="_blank">lcui@vmware.com</a>><br>
><br>
> Hi Youcef,<br>
><br>
> Both ways looks not good enough in my perspective. The<br>
> Atlas/Equilibrium style is too deep in hierarchy while the Quantum<br>
> style is a bit too flat. I think we may consider the following principles in API design:<br>
><br>
> 1. “part-of” relationship between objects. If object B is “part of”<br>
> object A, then the url hierarchy may look like /A/B.<br>
><br>
> 2. Object reuse. Can an object reused by multiple objects? If object<br>
> B can be referred by both A1 and A2, then B probably should be in the<br>
> same url level as A. For instance, in our design, do we prevent a<br>
> pool shared by multiple VIPs? If not, Pool should be in the same url<br>
> level as VIP. It’s the same for HealthMonitor object. A HealthMonitor<br>
> object should be able to bind to multiple pools (implicitly there will<br>
> be multiple healthMonitor instances created and bound to each pool member).<br>
><br>
><br>
><br>
> Not sure if we have the same understanding against the healthMonitor<br>
> concept. A healthMonitor object defines a type of monitor (e.g.<br>
> TCP/HTTP/HTTPS) with generic settings (e.g. interval, timeout). When<br>
> a healthMonitor is bound to a pool, the LBaaS system will implicitly<br>
> create a healthMonitorInstance object for each pool member, and by<br>
> default use the ipAddress/port of the pool member. I believe this is<br>
> how F5 Big-IP monitor is defined and we may follow this practice.<br>
><br>
><br>
><br>
> So my suggest would be, assuming all vips/pools/healthmonitors should<br>
> be only in a single tenant scope, then the following URLs should be used:<br>
><br>
> /lbaas/v1.0/tenants<br>
><br>
> /lbaas/v1.0/tenants/1000/vips<br>
><br>
> /lbaas/v1.0/tenants/1000/pools<br>
><br>
> /lbaas/v1.0/tenants/1000/healthmonitors<br>
><br>
> /lbaas/v1.0/tenants/1000/pools/1/members<br>
><br>
><br>
><br>
> Please let me know your thoughts.<br>
><br>
><br>
><br>
> Thanks<br>
><br>
> Leon<br>
><br>
> </span><span style="font-family:MingLiU;color:black">发件人</span><span style="color:black">: Youcef Laribi [mailto:<a href="mailto:Youcef.Laribi@eu.citrix.com" target="_blank">Youcef.Laribi@eu.citrix.com</a>]<br>
> </span><span style="font-family:MingLiU;color:black">发送时间</span><span style="color:black">: 2012</span><span style="font-family:"MS Gothic";color:black">年</span><span style="color:black">10</span><span style="font-family:"MS Gothic";color:black">月</span><span style="color:black">25</span><span style="font-family:"MS Gothic";color:black">日</span><span style="color:black">
9:02<br>
> </span><span style="font-family:"MS Gothic";color:black">收件人</span><span style="color:black">: Leon Cui; 'Busby, Brent'; 'Ilya Shakhat'<br>
> </span><span style="font-family:"MS Gothic";color:black">抄送</span><span style="color:black">: 'Kobi Samoray'; 'Dan Wendlandt'; 'Palanisamy, Anand'; 'John<br>
> Gruber'; 'Peter Mellquist'; 'Samuel Bercovici'; 'Rudra Rugge'; 'Alex<br>
> Gosse'; 'Serge Maskalik'; 'Naik, Chinmay'; 'Salvatore Orlando';<br>
> 'Eugene Nikanorov'; 'Oleg Bondarev'; 'Eugene Kirpichev'; 'Roman Alekseenkov'<br>
> </span><span style="font-family:"MS Gothic";color:black">主</span><span style="font-family:MingLiU;color:black">题</span><span style="color:black">: RE: Questions to REST API proposal<br>
><br>
><br>
><br>
> Both are valid ways of expressing the resource model but the payloads<br>
> for the objects would be different in each case.<br>
><br>
><br>
><br>
> If we take the Atlas/Equilibrium style, where the context is implied<br>
> from the URL:<br>
><br>
><br>
><br>
> <a href="http://lbaas-service/lbaas/v1.0/tenants/1000/vips/4/pools/1/members" target="_blank">
http://lbaas-service/lbaas/v1.0/tenants/1000/vips/4/pools/1/members</a><br>
><br>
><br>
><br>
> Here, we know we are talking about the members of pool 1 which<br>
> belongs to vip 4 of tenant 1000. There is an implied hierarchy by just<br>
> looking at the URL. When we create a member, the payload doesn’t need<br>
> to specify the vip, the pool and the tenant, since these are already<br>
> specified in the URL (and you can only create members through these<br>
> form of URLs). So, a member payload here could be:<br>
><br>
><br>
><br>
> {<br>
><br>
> "member": {<br>
><br>
> "address": "192.168.130.51",<br>
><br>
> "port" : 80,<br>
><br>
> "connectionlimit": 500,<br>
><br>
> "weight" : 2<br>
><br>
> "adminState" : "ENABLED"<br>
><br>
> }<br>
><br>
> }<br>
><br>
><br>
><br>
> Also, the IDs of members can be relative to pools, they don’t need to<br>
> be unique across pools and across vips and tenants (although you can<br>
> create unique ones in any case).<br>
><br>
><br>
><br>
> If we take however the Quantum style, where objects are defined at the<br>
> top-level, then we need to create a member like this:<br>
><br>
><br>
><br>
> POST <a href="http://lbaas-service/lbaas/v1.0/members" target="_blank">http://lbaas-service/lbaas/v1.0/members</a><br>
><br>
><br>
><br>
> {<br>
><br>
> "member": {<br>
><br>
> "tenant-id" : "1000",<br>
><br>
> "vip-id" : "4",<br>
><br>
> "pool-id" : "1",<br>
><br>
> "address": "192.168.130.51",<br>
><br>
> "port" : 80,<br>
><br>
> "connectionlimit": 500,<br>
><br>
> "weight" : 2<br>
><br>
> "adminState" : "ENABLED"<br>
><br>
> }<br>
><br>
> }<br>
><br>
><br>
><br>
><br>
><br>
> Here we needed to specify all the information that was implied before<br>
> from the URL, and these attributes are required each time we need to<br>
> create a member.<br>
><br>
><br>
><br>
> The advantage of the Quantum-style approach, is you can list all<br>
> members regardless of which vips, pools or tenants they belong to, by<br>
> simply doing the following:<br>
><br>
><br>
><br>
> GET <a href="http://lbaas-service/lbaas/v1.0/members" target="_blank">http://lbaas-service/lbaas/v1.0/members</a><br>
><br>
><br>
><br>
> This is especially useful for admin roles, where you want to list all<br>
> vips or all pools regardless of their containing object. This is hard<br>
> to do in Atlas/Equilibrium style (unless you have a convention that<br>
> can substitute an ID in the URL with a wildcard).<br>
><br>
><br>
><br>
> If however, you want to find out the members of pool 4 in vip 1 in<br>
> Quantum style, then you have to use a query string style of filtering:<br>
><br>
><br>
><br>
> GET <a href="http://lbaas-service/lbaas/v1.0/members?vip-id=1&pool-id=4" target="_blank">
http://lbaas-service/lbaas/v1.0/members?vip-id=1&pool-id=4</a><br>
><br>
><br>
><br>
> In Atlas/Equilibrium, this would simply be:<br>
><br>
><br>
><br>
> GET<br>
> <a href="http://lbaas-service/lbaas/v1.0/tenants/1000/vips/4/pools/1/members" target="_blank">
http://lbaas-service/lbaas/v1.0/tenants/1000/vips/4/pools/1/members</a><br>
><br>
><br>
><br>
> So, both approaches are valid (although with the Quantum style, you<br>
> can do arbitrary filtering on attributes).<br>
><br>
><br>
><br>
> I think we should adopt the same API style between Quantum and LBaaS,<br>
> otherwise it will be confusing for people using the API.<br>
><br>
><br>
><br>
> Youcef<br>
><br>
><br>
><br>
> From: Leon Cui [mailto:<a href="mailto:lcui@vmware.com" target="_blank">lcui@vmware.com</a>]<br>
> Sent: Wednesday, October 24, 2012 4:42 PM<br>
> To: 'Busby, Brent'; 'Ilya Shakhat'; Youcef Laribi<br>
> Cc: 'Kobi Samoray'; 'Dan Wendlandt'; 'Palanisamy, Anand'; 'John<br>
> Gruber'; 'Peter Mellquist'; 'Samuel Bercovici'; 'Rudra Rugge'; 'Alex<br>
> Gosse'; 'Serge Maskalik'; 'Naik, Chinmay'; 'Salvatore Orlando';<br>
> 'Eugene Nikanorov'; 'Oleg Bondarev'; 'Eugene Kirpichev'; 'Roman Alekseenkov'<br>
> Subject: </span><span style="font-family:"MS Gothic";color:black">答复</span><span style="color:black">: Questions to REST API proposal<br>
><br>
><br>
><br>
> I agree with Busby that sometimes we need this “as-part-of” relationship.<br>
> Pool:member is a good example.<br>
><br>
><br>
><br>
> The top class objects should be defined independently and between<br>
> them, the relationship is much like “association” which is defined by<br>
> referring to the objectId. In current LBaaS model, those top objects<br>
> would be VIP, Pool, HealthMonitor. We should define CRUD APIs for each top objects by root path:<br>
><br>
> /loadbalancer/vips<br>
><br>
> /loadbalancer/pools<br>
><br>
> /loadbalancer/healthmonitors<br>
><br>
><br>
><br>
> In my perspective, member is not a top class object because it’s only<br>
> meaningful only if it belong to a pool. The path for members should be:<br>
><br>
> /loadbalancer/pools/members<br>
><br>
><br>
><br>
> Thanks<br>
><br>
> Leon<br>
><br>
> </span><span style="font-family:MingLiU;color:black">发件人</span><span style="color:black">: Busby, Brent [mailto:<a href="mailto:bbusby@ebay.com" target="_blank">bbusby@ebay.com</a>]<br>
> </span><span style="font-family:MingLiU;color:black">发送时间</span><span style="color:black">: 2012</span><span style="font-family:"MS Gothic";color:black">年</span><span style="color:black">10</span><span style="font-family:"MS Gothic";color:black">月</span><span style="color:black">25</span><span style="font-family:"MS Gothic";color:black">日</span><span style="color:black">
0:25<br>
> </span><span style="font-family:"MS Gothic";color:black">收件人</span><span style="color:black">: Ilya Shakhat; Youcef Laribi<br>
> </span><span style="font-family:"MS Gothic";color:black">抄送</span><span style="color:black">: Kobi Samoray; Dan Wendlandt; Palanisamy, Anand; John Gruber; Peter<br>
> Mellquist; Samuel Bercovici; Rudra Rugge; Alex Gosse; Leon Cui; Serge<br>
> Maskalik; Naik, Chinmay; Salvatore Orlando; Eugene Nikanorov; Oleg<br>
> Bondarev; Eugene Kirpichev; Roman Alekseenkov<br>
> </span><span style="font-family:"MS Gothic";color:black">主</span><span style="font-family:MingLiU;color:black">题</span><span style="color:black">: Re: Questions to REST API proposal<br>
><br>
><br>
><br>
> For #1 – Sometimes the relationship between pool and member defines<br>
> the member.<br>
><br>
> For example: on a netscaler health monitors are bound at the service<br>
> level, which is the member in this API. If the user defines the<br>
> health monitors at the pool level, then we need to know what members<br>
> are part of the pool to bind the health monitor to all pool members.<br>
> Additional health monitors can be bound to the member individually,<br>
> but it's membership in the pool means that it must also have the<br>
> pool's health monitors bound. Should we show monitors bound to the pool when listing just the member independently?<br>
> Should we allow the user to remove the health monitors bound to the<br>
> member via pool membership?<br>
><br>
><br>
><br>
> There are probably other examples where member inherits some trait<br>
> from the pool, but this is just the first example that popped in me head.<br>
><br>
><br>
><br>
> ________________________________<br>
><br>
> M. Brent Busby<br>
><br>
> eBay, Inc.<br>
><br>
> <a href="tel:602-316-8599" target="_blank">602-316-8599</a><br>
><br>
><br>
><br>
> From: Ilya Shakhat <<a href="mailto:ishakhat@mirantis.com" target="_blank">ishakhat@mirantis.com</a>><br>
> Date: Wednesday, October 24, 2012 4:17 AM<br>
> To: Youcef Laribi <<a href="mailto:Youcef.Laribi@eu.citrix.com" target="_blank">Youcef.Laribi@eu.citrix.com</a>><br>
> Cc: Kobi Samoray <<a href="mailto:KobiS@radware.com" target="_blank">KobiS@radware.com</a>>, "M. Brent Busby"<br>
> <<a href="mailto:bbusby@ebay.com" target="_blank">bbusby@ebay.com</a>>, Dan Wendlandt <<a href="mailto:dan@nicira.com" target="_blank">dan@nicira.com</a>>, "Palanisamy, Anand"<br>
> <<a href="mailto:apalanisamy@paypal.com" target="_blank">apalanisamy@paypal.com</a>>, John Gruber <<a href="mailto:J.Gruber@F5.com" target="_blank">J.Gruber@F5.com</a>>, Peter<br>
> Mellquist <<a href="mailto:peter.mellquist@hp.com" target="_blank">peter.mellquist@hp.com</a>>, Samuel Bercovici<br>
> <<a href="mailto:SamuelB@Radware.com" target="_blank">SamuelB@Radware.com</a>>, Rudra Rugge <<a href="mailto:rrugge@vmware.com" target="_blank">rrugge@vmware.com</a>>, Alex Gosse<br>
> <<a href="mailto:Alex.Gosse@riverbed.com" target="_blank">Alex.Gosse@riverbed.com</a>>, Leon Cui <<a href="mailto:lcui@vmware.com" target="_blank">lcui@vmware.com</a>>, Serge Maskalik <<a href="mailto:smaskalik@vmware.com" target="_blank">smaskalik@vmware.com</a>>,
"Naik, Chinmay"<br>
> <<a href="mailto:cnaik@paypal.com" target="_blank">cnaik@paypal.com</a>>, Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>>, Eugene<br>
> Nikanorov <<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>>, Oleg Bondarev<br>
> <<a href="mailto:obondarev@mirantis.com" target="_blank">obondarev@mirantis.com</a>>, Eugene Kirpichev <<a href="mailto:ekirpichev@mirantis.com" target="_blank">ekirpichev@mirantis.com</a>>,<br>
> Roman Alekseenkov <<a href="mailto:ralekseenkov@mirantis.com" target="_blank">ralekseenkov@mirantis.com</a>><br>
> Subject: Questions to REST API proposal<br>
><br>
><br>
><br>
> Hi Youcef,<br>
><br>
><br>
><br>
> We have some questions on REST API discussion.<br>
><br>
><br>
><br>
> 1) In Quantum API all objects "live" independently, even if they<br>
> depend on each other (like subnet and network). List of subnets can be<br>
> queried by request '/v2.0/subnets' and network_id is optional<br>
> parameter to request. In LBaaS we had a different style, and dependent<br>
> objects were accessible by sub-path (loadbalancers/loadbalancer-id/nodes).<br>
><br>
> From our perspective "plain" style is more preferable, since it would<br>
> be easier for client to access object by its id only and parent id is<br>
> superfluous. If needed the parent id may be set as filter (HTTP parameter).<br>
> For example, we propose to change:<br>
> '/vips/{vipId}/pools/{poolId}/members/{memberId}' -> '/members/{memberId}'.<br>
><br>
><br>
><br>
> 2) In VIP we have attribute 'networkId'. It allows LBaaS to create IP<br>
> address in the specified network, so the user doesn't need to do it<br>
> separately. I see how this will work for HW LB, but how will this work<br>
> for virtual? If virtual LB is created by user, then user may decide to<br>
> keep it accessible internal (=leave IP provided by Nova), or make it<br>
> external (=associate FIP). So in that case LBaaS needs to deal with<br>
> Quantum Port rather than with Quantum Network object. What do you think about this?<br>
><br>
><br>
><br>
> 3) For some items we need a way to provide extra parameters, for<br>
> example 'sessionPersistence' may have parameter 'http_header_name'.<br>
> How will we store them? As json-object under 'extra' attribute?<br>
><br>
><br>
><br>
> Thanks,<br>
><br>
> Ilya<br>
><br>
><br>
><br>
><br>
><br>
><br>
<br>
<br>
<br>
--<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
Dan Wendlandt<br>
Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br>
twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<o:p></o:p></span></p>
</div>
</div>
</div>
<p class="MsoNormal"><span style="color:black"> <o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:black"> </span><span style="color:black"><o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span style="font-family:"Arial","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
</div>
</div>
</body>
</html>