[openstack-dev] [Quantum] Final Questions on Load Balancing APIs

Salvatore Orlando sorlando at nicira.com
Sat Dec 8 00:36:11 UTC 2012


Hello again,

as the patches for the API and relevant DB support are getting ready
to be merged, I have some questions on a few more details of the load
balancing API.
I have been mulling over those details in the past few days, and in
this email I will discuss only the details I could not figure out by
myself.

1) Pool Status

Does a pool have a status of his own, or is the status of the pool a
function of the state of its members? For example, is it possible that
the pool is in ERROR state while all of its members are ACTIVE?

2) PENDING CREATE, PENDING UPDATE, and PENDING DELETE

I am not discussing the rationale behind these stata; however one
would expect that the plugin, via a driver would perform the
transition from a PENDING to a definite state. Shall the currently
proposed DB support class include methods for handling the 'state
machine' for LB resources?
Also, I cannot really understand PENDING DELETE in the way it's
currently implemented, as we set the status to this value and then
delete the resource from the DB immediately after. Is that intended
behaviour?

3) Operating on 'transient' or error resources

I see that operations on resources which are in a PENDING or ERROR
state will raise a StateInvalid Operation. More than a year ago we had
the same discussion for Quantum core resources, and we concluded that
API operations at the end of the day where just altering a DB model.
This should be allowed regardless of the operational status of a
resource. For instance if a resource is in ERROR it might make sense
to a user to set it administratively down; another example might be
setting the LB method on a pool while the pool itself is in PENDING
CREATE state. The subsequent change in the LB method will be
eventually picked up by the driver and the underlying configuration
updated. So why ask the user to poll on the resource (or subscribe to
notifications that we do not have yet anyway).

4) Association between pool and network.

This association is kind of making an assumption that all members are
on the same network. If this is correct, I am wondering whether this
assumption holds in real basic use cases. A network in Quantum is
representative of a single l2 broadcast domain. Load Balancers, being
much above in the stack, should be able to add members from different
networks. At the beginning I thought this was going to be addressed by
having n pools for each VIP, but it seems this is not the case. Even
for basic use cases, I think this might be a little limiting. Do you
think there might a case for doing Load Balancing with members across
multiple networks since v1.0?
Also, you probably want to consider having a subnet_id instead of a
network_id. This is because a network might have multiple subnets, and
a load balancer driver will likely need an IP address on this subnet
as it will be used a source IP in the communication with the members
of the pool.

Thanks for taking time to read this email. Your feedback is much appreciated.

Regards,
Salvatore



More information about the OpenStack-dev mailing list