Open Stack

Hi Youcef,

Thanks for writing down the API spec.  I went through the spec and overall
looks great!



Just a few comments from my side:



1.       [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.



2.       A pool can have several health monitors associated with it.

[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.



3.       HTTPS: used to send a secure HTTP request to the member.

[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.



4.        [Leon] We should support SSL_SessionID based session persistence
for HTTPS protocol (actually it’s SSL passthrough)



5.       [Leon] Shall we add “rate_limit” as part of VIP to enhance
anti-DoS ability.



6.       Connectin_limit property

[Leon] connection_limit could be a property of member. In “connection
limits”, you have said that “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.



7.       HTTPS Health Monitor

[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.



Thanks

Leon

发件人: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com]
发送时间: 2012年10月30日 2:24
收件人: Ilya Shakhat
抄送: 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 (openstack-dev at lists.openstack.org)
主题: RE: [openstack-dev][Quantum][LBaaS] LBaaS API 1.0 spec draft



Hi Ilya,



Thanks to you and the team for your detailed review and your comments,
much appreciated! Let me go through them:

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.

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.

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?

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”.



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.

Yes good point. I’ll update the spec.

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.

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.

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?

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.



Let's add a note that all update operations adopt patch semantics (like
Quantum does)

Good point. Yes, the semantics of “PUT” in REST is not universally
agreed upon J



Normal Response Code for 'List VIPs' and 'Retrieve VIP details' should be
200 (not 202)

In 'Delete Health Monitor' operation the title for example should be
"Delete a TCP Monitor" (not Update)

Good catches. Will update.

Youcef



From: Ilya Shakhat [mailto:ishakhat at mirantis.com]
Sent: Monday, October 29, 2012 6:59 AM
To: Youcef Laribi
Cc: 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 (openstack-dev at lists.openstack.org)
Subject: Re: [openstack-dev][Quantum][LBaaS] LBaaS API 1.0 spec draft



Youcef,



Please find comments and questions below:

1.	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.
2.	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?
3.	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.
4.	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.
5.	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?
6.	Let's add a note that all update operations adopt patch semantics
(like Quantum does)
7.	Normal Response Code for 'List VIPs' and 'Retrieve VIP details'
should be 200 (not 202)
8.	In 'Delete Health Monitor' operation the title for example should
be "Delete a TCP Monitor" (not Update)

Thanks for great job on putting this together! We are ready to start the
implementation.



Ilya.





2012/10/27 Youcef Laribi <Youcef.Laribi at eu.citrix.com>

I have put a first draft of the LBaaS API on the wiki page
http://wiki.openstack.org/Quantum/LBaaS/API_1.0, 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.



Thanks,

Youcef

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121029/008ba431/attachment-0001.html>