<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:12.0pt;
font-family:"Times New Roman","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:9.0pt;
font-family:SimSun;
mso-fareast-language:ZH-CN;}
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";
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";
mso-fareast-language:ZH-CN;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#993366;}
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:12.0pt;
font-family:"Times New Roman","serif";
mso-fareast-language:ZH-CN;}
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;}
span.EmailStyle24
{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:457376786;
mso-list-type:hybrid;
mso-list-template-ids:-450699656 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1
{mso-list-id:1724788432;
mso-list-template-ids:1263039344;}
@list l1:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2
{mso-list-id:1951009204;
mso-list-template-ids:-626223538;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi Leon,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366'><o:p> </o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366'><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:#993366'>[Leon] I agree with Ilya that we shouldn’t put lbMethod as part of VIP. It’s kinda of duplicate of lbMethod in Pool and confusing to user. In future when we want to support L7 rules, no need to add lbMethod to VIP any more.<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'>Yes. This is now part of the Pool as we discussed 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='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366'><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:#993366'>A pool can have several health monitors associated with it. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366'>[Leon] I think we need to elaborate the condition for multiple health monitors. In the first release, the implicit condition should be AND, which means the health status will be OK only if all health monitors is OK.<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'>Yes agree. I will make this clear in the spec.<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:l0 level1 lfo2'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366'><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:#993366'>HTTPS: used to send a secure HTTP request to the member.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366'>[Leon] I assume this monitor is using ssl-hello message to detect the health of member which is a HTTPS server. Otherwise, we need to provide the client certificate.<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'>There is no need for a client cert. The monitor is just opening a secure SSL connection to the HTTPS server, just like HTTP case and then fire the request and examines the returned HTTP status code.<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:l0 level1 lfo2'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366'><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:#993366'> [Leon] We should support SSL_SessionID based session persistence for HTTPS protocol (actually it’s SSL passthrough)<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'>This was discussed during the last summit, and it was felt that this is not useful to support as a persistence method, as SSL session ids tend to last for just a few minutes.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366'><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:#993366'>[Leon] Shall we add “rate_limit” as part of VIP to enhance anti-DoS ability.<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'>We had this in Atlas, and we discussed it at the summit too, and it was agreed that in 1.0, we will support simple absolute limits.<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:l0 level1 lfo2'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366'><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:#993366'>Connectin_limit property<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366'>[Leon] connection_limit could be a property of member. In “connection limits”, you have said that “</span><span style='font-size:10.5pt;font-family:"Arial","sans-serif";color:#535353;background:white'>To control incoming traffic on the VIP address as well as traffic for a specific member of a pool,”, therefore we need member level connection throttling.</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366'><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'>Sorry if the text is misleading, but I meant the same limit applies to each member of the pool. We won’t have a different limit per member.<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:l0 level1 lfo2'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366'><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:#993366'>HTTPS Health Monitor<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366'>[Leon] If HTTPS health monitor is using ssl-hello message mechanism, http_method/url_path/expected_codes properties is only valid for HTTP Health Monitor. Otherwise, we need to provide client certificate/key/cipher properties.<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'>See my previous comment on 4.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366'>Thanks<o:p></o:p></span></p></div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366'>Leon<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 again Leon for your careful review of 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=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Youcef<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><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:[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>10<span lang=ZH-CN>月</span>30<span lang=ZH-CN>日</span> 2:24<br><b><span lang=ZH-CN>收件人</span>:</b> Ilya Shakhat<br><b><span lang=ZH-CN>抄送</span>:</b> Sachin Thakkar; Serge Maskalik; Eugene Nikanorov; 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; OpenStack Development Mailing List (<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>)<br><b><span lang=ZH-CN>主题</span>:</b> RE: [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'>Hi Ilya,<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 to you and the team for your detailed review and your comments, much appreciated! Let me go through them:<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>Last Tuesday we discussed where to put 'lb_method' attribute and decided to keep it in both VIP and Pool and implement inheritance. Well.. from fresh view this looks confusing, There will be some users who will operate with lb_method via VIP and others - via Pool, and sooner or later one type will take over other. The inheritance could be useful if we had >1 pools, but we've decided to put this out of core scope. For case of multiple pools it would be more appropriate to call attribute 'selector' or 'rule', just like in F5.<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Yes only one pool is supported in Core API, but we wanted to keep the door open to people who want to build L7 rules extensions and add several pools. In this case, they will need the lb_method on pool as each pool might be using a different method for load-balancing. But I guess, if they are extending the VIP object (to configure L7 rules and to add “extra” pools), they can also extend the Pool object and add an “lb_method” attribute to it too, so this can be removed from core. Let’s discuss this in tomorrow’s meeting.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>How to retrieve error details for async calls? May we add an attribute 'error_details' to all objects and fill it in case of error?<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Good question. Ideally, all validation should be done on the request at submission time, and once it is accepted, the request should succeed asynchronously on the plugin. But realistically, validation might not be rigorous enough at submission time, and an error might still be discovered later by the plugin, so when status of a resource is set to “ERROR”, we could have another field as you suggest in all resources explaining what caused the status to be set to “ERROR”.<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 style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>For DELETE requests if no body is returned then HTTP code should be 204 "No Content". As an alternative way we may want to return object that is scheduled for deletion with status=PENDING_DELETE and HTTP code 202.<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Yes good point. I’ll update the spec.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>We introduced operations to retrieve list of supported protocols and LB methods. Besides these there are two more that are driver-dependent: health monitoring and session persistence. I suppose we need to add operations for them too.<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I would regard the type of health monitors and session persistence methods described in the spec as mandatory for all drivers to supported. If they are not supported by some drivers, then we should remove them from the core spec. There should be some guarantee for users of the API that some functionality is supported by al drivers/plugins. Extensions (through drivers) can add extra lb methods, protocols, health monitors, session persistence types, etc. May be we can replace this by a capability call to list everything rather than having a separate API for each. I’ll see what the other OpenStack projects do.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>In Remove a Pool operation there's a note: "Attempting to remove a pool that is used in a VIP will result in a badRequest (400) error. First remove the pool from the VIP, then you can destroy the pool and its members." Since VIP.pool_id is now scalar value would it be more correct to require removal of the whole VIP object before removing Pool?<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I don’t think this will entirely solve the problem because sometimes you might want to remove the pool but keep the VIP. The idea I had is that you remove the pool from the VIP by replacing it the VIP’s pool_id with another Pool that you created. That way, you ensure that a VIP always has a pool and at the same time, break the association between the VIP and the old pool. The old pool now being free (not attached to any VIP), can be safely removed.<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 style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>Let's add a note that all update operations adopt patch semantics (like Quantum does)<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Good point. Yes, the semantics of “PUT” in REST is not universally agreed upon </span><span style='font-size:11.0pt;font-family:Wingdings;color:#1F497D'>J</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><a name="_MailEndCompose"></a><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>Normal Response Code for 'List VIPs' and 'Retrieve VIP details' should be 200 (not 202)<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'>In 'Delete Health Monitor' operation the title for example should be "Delete a TCP Monitor" (not Update)<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Good catches. Will update.</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Youcef<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><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"'> Ilya Shakhat <a href="mailto:[mailto:ishakhat@mirantis.com]">[mailto:ishakhat@mirantis.com]</a> <br><b>Sent:</b> Monday, October 29, 2012 6:59 AM<br><b>To:</b> Youcef Laribi<br><b>Cc:</b> Sachin Thakkar; Serge Maskalik; Eugene Nikanorov; 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; OpenStack Development Mailing List (<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>)<br><b>Subject:</b> Re: [openstack-dev][Quantum][LBaaS] LBaaS API 1.0 spec draft<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Youcef, <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Please find comments and questions below:<o:p></o:p></p></div><div><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo5'>Last Tuesday we discussed where to put 'lb_method' attribute and decided to keep it in both VIP and Pool and implement inheritance. Well.. from fresh view this looks confusing, There will be some users who will operate with lb_method via VIP and others - via Pool, and sooner or later one type will take over other. The inheritance could be useful if we had >1 pools, but we've decided to put this out of core scope. For case of multiple pools it would be more appropriate to call attribute 'selector' or 'rule', just like in F5.<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo5'>How to retrieve error details for async calls? May we add an attribute 'error_details' to all objects and fill it in case of error?<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo5'>For DELETE requests if no body is returned then HTTP code should be 204 "No Content". As an alternative way we may want to return object that is scheduled for deletion with status=PENDING_DELETE and HTTP code 202.<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo5'>We introduced operations to retrieve list of supported protocols and LB methods. Besides these there are two more that are driver-dependent: health monitoring and session persistence. I suppose we need to add operations for them too.<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo5'>In Remove a Pool operation there's a note: "Attempting to remove a pool that is used in a VIP will result in a badRequest (400) error. First remove the pool from the VIP, then you can destroy the pool and its members." Since VIP.pool_id is now scalar value would it be more correct to require removal of the whole VIP object before removing Pool?<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo5'>Let's add a note that all update operations adopt patch semantics (like Quantum does)<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo5'>Normal Response Code for 'List VIPs' and 'Retrieve VIP details' should be 200 (not 202)<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo5'>In 'Delete Health Monitor' operation the title for example should be "Delete a TCP Monitor" (not Update)<o:p></o:p></li></ol></div><div><p class=MsoNormal>Thanks for great job on putting this together! We are ready to start the implementation.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Ilya.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>2012/10/27 Youcef Laribi <<a href="mailto:Youcef.Laribi@eu.citrix.com" target="_blank">Youcef.Laribi@eu.citrix.com</a>><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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" target="_blank">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.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><a name="13aa02e2989a0a02__MailEndCompose"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Youcef</span></a><o:p></o:p></p></div></body></html>