<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=gb2312"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:SimSun;
        panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
        {font-family:SimSun;
        panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:"\@SimSun";
        panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";
        mso-fareast-language:ZH-CN;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";
        mso-fareast-language:ZH-CN;}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";}
span.Char
        {mso-style-name:"\6279\6CE8\6846\6587\672C Char";
        mso-style-priority:99;
        mso-style-link:\6279\6CE8\6846\6587\672C;
        font-family:SimSun;}
p.a, li.a, div.a
        {mso-style-name:\6279\6CE8\6846\6587\672C;
        mso-style-link:"\6279\6CE8\6846\6587\672C Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";
        mso-fareast-language:ZH-CN;}
span.EmailStyle21
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
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:#993366;}
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:#003300;}
span.EmailStyle26
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.EmailStyle27
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.EmailStyle28
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.EmailStyle29
        {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.25in 1.0in 1.25in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='color:#1F497D'>The Core API (for Grizzly) supports the simple use cases that can be easily implemented by all vendors. <o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>We had a long consultation period around the API spec to give a chance to everyone to provide their input, and now it is more or less locked, apart from small changes to facilitate implementation for Grizzly release. Extra use cases (multiple pools per VIP, multiple VIPs per pool, member stats, L7 rules, etc.) can always be implemented as extensions for now by vendors who wish to do so, and in future releases could be folded into Core if we have consensus. <o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Having said this, if the rest of the team feel we should add the use case of “multiple vips sharing the same pool” to the resource model and API, then I can amend the API spec accordingly. I would note though, that this would complicate vip scheduling, since 2 or more vips sharing the same pool, would need to be placed on the same device. The vip stats would also be less meaningful and we might need to move to per-pool stats.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Thanks<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Youcef<o:p></o:p></span></p><p class=MsoNormal><span style='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"'> Samuel Bercovici [mailto:SamuelB@Radware.com] <br><b>Sent:</b> Friday, December 07, 2012 12:32 PM<br><b>To:</b> OpenStack Development Mailing List<br><b>Subject:</b> Re: [openstack-dev] </span><span lang=ZH-CN style='font-size:10.0pt;font-family:SimSun'>答复</span><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>: [Quantum][LBaaS] vip_id in pool creation API<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='color:#1F497D'>Hi,<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><br>I think that the most common use case is using a pool with multiple vip services (ex: 1.1.1.1:80 and 1.1.1.1:443)<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>In the proposed model, if we have the same group of nodes participating in multiple say services on port 80 and 443, we need to specify two vips (since we did not separate between the IP address and the port) and will need to create two pools.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>I would expect us to be able to reuse the pool.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>What am I missing?<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Regards,<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>                -Sam.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='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:Youcef.Laribi@eu.citrix.com">mailto:Youcef.Laribi@eu.citrix.com</a>] <br><b>Sent:</b> Friday, December 07, 2012 10:20 PM<br><b>To:</b> OpenStack Development Mailing List<br><b>Subject:</b> Re: [openstack-dev] </span><span lang=ZH-CN style='font-size:10.0pt;font-family:SimSun'>答复</span><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>: [Quantum][LBaaS] vip_id in pool creation API<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='color:#1F497D'>Hi Sam,<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>We discussed all of this before and at the last Summit at length </span><span style='font-family:Wingdings;color:#1F497D'>J</span><span style='color:#1F497D'> Just like Quantum resources, we model all resources as top resources regardless of the arity of their relationship to each other. This also allows extensions can add more pools to a VIP (e.g. for L7 LB).<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Youcef<o:p></o:p></span></p><p class=MsoNormal><span style='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"'> Samuel Bercovici [<a href="mailto:SamuelB@Radware.com">mailto:SamuelB@Radware.com</a>] <br><b>Sent:</b> Friday, December 07, 2012 12:07 PM<br><b>To:</b> OpenStack Development Mailing List; Youcef Laribi<br><b>Subject:</b> RE: [openstack-dev] </span><span lang=ZH-CN style='font-size:10.0pt;font-family:SimSun'>答复</span><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>: [Quantum][LBaaS] vip_id in pool creation API<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='color:#1F497D'>Hi,<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>If vips and pools have 1:1 relationships, why do we need pools as first citizens?<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Regards,<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>                -Sam.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='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"'> Leon Cui [<a href="mailto:lcui@vmware.com">mailto:lcui@vmware.com</a>] <br><b>Sent:</b> Friday, December 07, 2012 2:25 AM<br><b>To:</b> 'Youcef Laribi'<br><b>Cc:</b> <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br><b>Subject:</b> [openstack-dev] </span><span lang=ZH-CN style='font-size:10.0pt;font-family:SimSun'>答复</span><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>: [Quantum][LBaaS] vip_id in pool creation API<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='color:#003300'>Sounds good.  Thanks Youcef.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#003300'><o:p> </o:p></span></p><div><p class=MsoNormal><span style='color:#003300'>Thanks<o:p></o:p></span></p></div><p class=MsoNormal><span style='color:#003300'>Leon<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 lang=ZH-CN style='font-size:10.0pt;font-family:SimSun'>发件人</span></b><b><span style='font-size:10.0pt;font-family:SimSun'>:</span></b><span style='font-size:10.0pt;font-family:SimSun'> Youcef Laribi [<a href="mailto:Youcef.Laribi@eu.citrix.com">mailto:Youcef.Laribi@eu.citrix.com</a>] <br><b><span lang=ZH-CN>发送时间</span>:</b> 2012<span lang=ZH-CN>年</span>12<span lang=ZH-CN>月</span>6<span lang=ZH-CN>日</span> 15:30<br><b><span lang=ZH-CN>收件人</span>:</b> Leon Cui<br><b><span lang=ZH-CN>抄送</span>:</b> <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br><b><span lang=ZH-CN>主题</span>:</b> RE: [Quantum][LBaaS] vip_id in pool creation API<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='color:#1F497D'>Hi Leon,<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>I’m assuming that when someone creates a pool and mentions a vip_id, we automatically also update the vip object with the new pool_id (to keep them in sync). But you are right, it’s simpler to have it read-only in the pool, and allow update only from the vip object. I’ll change the spec accordingly. I will also add the restriction that a pool can only be used in a vip if it is not already used by another vip (ie. Pools cannot be shared between vips, it’s 1:1). <o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Thanks<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Youcef  <o:p></o:p></span></p><p class=MsoNormal><a name="_MailEndCompose"><span style='color:#1F497D'>                                                                                                                                                                                                                                                         </span></a><span style='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"'> Leon Cui [<a href="mailto:lcui@vmware.com">mailto:lcui@vmware.com</a>] <br><b>Sent:</b> Thursday, December 6, 2012 3:12 PM<br><b>To:</b> Youcef Laribi<br><b>Cc:</b> <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br><b>Subject:</b> </span><span lang=ZH-CN style='font-size:10.0pt;font-family:SimSun'>答复</span><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>: [Quantum][LBaaS] vip_id in pool creation API<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='color:#993366'>Hi Youcef,<o:p></o:p></span></p><p class=MsoNormal><span style='color:#993366'>That’s exactly what I suggest that don’t place a “vip_id” inside pool creation payload.  In this way, “vip_id” is a ready-only property in pool and we can avoid the case that you mentioned. <o:p></o:p></span></p><p class=MsoNormal><span style='color:#993366'>Currently API spec said that “vip_id” could be provided during pool creation (POST) call. It potentially allows someone to create a pool to be associated with a VIP which still think is associated with another pool.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#993366'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#993366'>Correct me if my statement is wrong.  thanks<o:p></o:p></span></p><p class=MsoNormal><span style='color:#993366'><o:p> </o:p></span></p><div><p class=MsoNormal><span style='color:#993366'>Thanks<o:p></o:p></span></p></div><p class=MsoNormal><span style='color:#993366'>Leon<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 lang=ZH-CN style='font-size:10.0pt;font-family:SimSun'>发件人</span></b><b><span style='font-size:10.0pt;font-family:SimSun'>:</span></b><span style='font-size:10.0pt;font-family:SimSun'> Youcef Laribi [<a href="mailto:Youcef.Laribi@eu.citrix.com">mailto:Youcef.Laribi@eu.citrix.com</a>] <br><b><span lang=ZH-CN>发送时间</span>:</b> 2012<span lang=ZH-CN>年</span>12<span lang=ZH-CN>月</span>5<span lang=ZH-CN>日</span> 11:56<br><b><span lang=ZH-CN>收件人</span>:</b> Leon Cui<br><b><span lang=ZH-CN>抄送</span>:</b> <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br><b><span lang=ZH-CN>主题</span>:</b> RE: [Quantum][LBaaS] vip_id in pool creation API<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='color:#1F497D'>Hi Leon,<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>The reason the spec said this is to ensure that the information in the VIP (which pool_id is used by the VIP) and the information in the pool (to which VIP the pool belongs, if it belongs to one), never get out-of-sync. If we allowed separate updates, then someone can update the pool to be associated with a new VIP, but the old VIP still thinks the pool is associated with it. <o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Youcef<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='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"'> Leon Cui [<a href="mailto:lcui@vmware.com">mailto:lcui@vmware.com</a>] <br><b>Sent:</b> Wednesday, December 5, 2012 10:24 AM<br><b>To:</b> Youcef Laribi<br><b>Cc:</b> <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br><b>Subject:</b> [Quantum][LBaaS] vip_id in pool creation API<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Hi Youcef,<o:p></o:p></p><p class=MsoNormal>In Create_Pool API, the spec says “Optionally, you can also assign the pool to a vip during creation time, by specifying the vip_id attribute.”.  I don’t think we should allow user to do it because it means that it will modify the “pool_id” of a VIP in an implicitly way.  I suggest that don’t allow user to provide vip_id during pool creation api. User can always to update the VIP by given a different pool_id. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>What do you think?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks<o:p></o:p></p><p class=MsoNormal>Leon<o:p></o:p></p></div></body></html>