<div>Youcef, </div><div><br></div><div>Please find comments and questions below:</div><div><ol><li>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.</li>
<li>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?</li><li>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.</li>
<li>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.</li>
<li>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?</li>
<li>Let's add a note that all update operations adopt patch semantics (like Quantum does)</li><li>Normal Response Code for 'List VIPs' and 'Retrieve VIP details' should be 200 (not 202)</li><li>In 'Delete Health Monitor' operation the title for example should be "Delete a TCP Monitor" (not Update)</li>
</ol></div><div>Thanks for great job on putting this together! We are ready to start the implementation.</div><div><br></div><div>Ilya.</div><div><br></div><br><div class="gmail_quote">2012/10/27 Youcef Laribi <span dir="ltr"><<a href="mailto:Youcef.Laribi@eu.citrix.com" target="_blank">Youcef.Laribi@eu.citrix.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><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" 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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks,<u></u><u></u></span></p>
<p class="MsoNormal"><a name="13aa02e2989a0a02__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Youcef</span></a></p></div></div></blockquote></div>