<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 14 (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:MingLiU;
panose-1:2 2 5 9 0 0 0 0 0 0;}
@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.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;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle26
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.string1
{mso-style-name:string1;
color:#004080;}
span.EmailStyle28
{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: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 l0:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1
{mso-list-id:983508531;
mso-list-type:hybrid;
mso-list-template-ids:1733047932 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l2
{mso-list-id:1336495973;
mso-list-type:hybrid;
mso-list-template-ids:1320853790 -1320403494 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l2: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";}
@list l2:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3
{mso-list-id:1903516185;
mso-list-type:hybrid;
mso-list-template-ids:1830481320 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l3:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l3:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l3:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l3:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l3:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l3:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l3:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l3:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l3:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
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:10.0pt;font-family:"Tahoma","sans-serif";color:black'>Hi Peter,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>Let me try to answer your comments.<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 lfo2'><![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:l2 level1 lfo4'><![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:l2 level1 lfo4'><![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:l2 level1 lfo4'><![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=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:black'>Currently OpenStack projects are not uniform with this respect. The following projects do seem to have XSDs:<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l3 level1 lfo6'><![if !supportLists]><span style='font-size:11.0pt;font-family:Symbol;color:black'><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:black'>Compute: </span><a href="https://github.com/openstack/compute-api/tree/master/openstack-compute-api-2/src/xsd">https://github.com/openstack/compute-api/tree/master/openstack-compute-api-2/src/xsd</a><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l3 level1 lfo6'><![if !supportLists]><span style='font-size:11.0pt;font-family:Symbol;color:black'><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:black'>Keystone: </span><a href="https://github.com/openstack/identity-api/tree/master/openstack-identity-api/src/docbkx/common/xsd">https://github.com/openstack/identity-api/tree/master/openstack-identity-api/src/docbkx/common/xsd</a><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>But Glance, Cinder, Swift and Quantum don’t seem to have these. And even if we define these, they are not used today for code generation, just for documentation I believe. But we can certainly define XSDs for LBaaS and try hard to keep them up-to-date.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoListParagraph style='margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo2'><![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:l2 level1 lfo4'><![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:l2 level1 lfo4'><![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:l2 level1 lfo4'><![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=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:black'>I believe we are going rely on Quantum for KeyStone integration since the LBaaS APIs are going to be implemented as a Quantum API extension, so whatever KeyStone’s version Quantum supports, we will inherit the same. May be someone from the Quantum team can clarify this further. If Quantum will integrate with KeyStone 2 in Grizzly, then I’ll call out this in the spec for LBaaS.<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 lfo2'><![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:l2 level1 lfo4'><![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><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:black'>Here again, not all OpenStack APIs support pagination. The following APIs do:<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='text-indent:-.25in;mso-list:l1 level1 lfo8'><![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:black'>Compute</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>: </span><a href="http://docs.openstack.org/api/openstack-compute/2/content/Paginated_Collections-d1e664.html">http://docs.openstack.org/api/openstack-compute/2/content/Paginated_Collections-d1e664.html</a><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo8'><![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]>KeyStone: <a href="http://docs.openstack.org/api/openstack-identity-service/2.0/content/Paginated_Collections-d1e325.html">http://docs.openstack.org/api/openstack-identity-service/2.0/content/Paginated_Collections-d1e325.html</a><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo8'><![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]>Swift:<span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><a href="http://docs.openstack.org/api/openstack-object-storage/1.0/content/paging-objects.html">http://docs.openstack.org/api/openstack-object-storage/1.0/content/paging-objects.html</a><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><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=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>But Glance, Cinder and Quantum don’t seem to support pagination. We’ll discuss this in the next meeting as to whether to introduce this in LBaaS. I certainly would like to see it.<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 lfo2'><![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:l2 level1 lfo4'><![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:l2 level1 lfo4'><![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=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>This was written before I understood how Quantum implements Bulk operations. Given the complexity of doing rollback and reporting errors on bulk, we decided in the last meeting that we are going to postpone support for this (not in first release). Do you feel differently about 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><p class=MsoListParagraph style='margin-left:.75in;text-indent:-.25in;mso-list:l0 level1 lfo2'><![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:l2 level1 lfo4'><![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:l2 level1 lfo4'><![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=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>See previous answer on XSD use :-)<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 lfo2'><![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:l2 level1 lfo4'><![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=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>Good point. I agree, it would be useful to have tenant resource limits returned by the service. For the sake of resource management, we would need a limit anyway.<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 lfo2'><![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:l2 level1 lfo4'><![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:l2 level1 lfo4'><![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=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>Yes </span><span style='font-size:11.0pt;font-family:Wingdings;color:black'>J</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'> This is what was decided in the last meeting.<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 lfo2'><![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:l2 level1 lfo4'><![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=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>Agreed. Will update the doc.<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 lfo2'><![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:l2 level1 lfo4'><![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=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>Yes you are right, we do need to clarify the service’s behavior wrt collecting stats.<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 lfo2'><![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:l2 level1 lfo4'><![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:l2 level1 lfo4'><![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:l2 level1 lfo4'><![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:black'>The idea here, is that when you delete a resource, the LBaaS service knows what other resources are using it and will update the references. So for example, if you delete a member, the pool’s array of members is automatically updated. So, there should be no dangling references.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>Thanks again Peter for your thorough reading and comments !<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>Youcef<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><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 <a href="mailto:[mailto:Youcef.Laribi@eu.citrix.com]">[mailto:Youcef.Laribi@eu.citrix.com]</a> <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 (<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>)<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>