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

Youcef Laribi Youcef.Laribi at eu.citrix.com
Sat Dec 8 02:30:59 UTC 2012


Hi Salvatore,



Added the [LBaaS] tag to the subject line...



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?



Yes, usually the pool's status is determined by that of its members. But there are cases where if you try to update a property on the pool itself (like health monitors), and this is refused by the driver (for whatever reason), then the pool will be in ERROR status (and this has nothing to do with the status of its members). In any case, this is a driver issue, so if for whatever reason, the driver returns an error for an operation on the pool, we should set it in the DB to this state.



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?



I let Leon answer, as I haven't reviewed the code.



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



The problem with accepting updates while the object is in a PENDING_* state is we have to queue these operations on the driver, while the first operation is still pending. And after this, if there is an error, it is difficult to convey to the user which of the last N operations has failed, or may be several. It was a simpler model to do one update at a time, and wait for it until it either succeeds or fails, before making another update.



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?



Yes the current model is all members of the pool are on the same L2/L3 network. This supports the primary case of load-balancing a web-tier, or an app-tier, where all VMs are on the same network. Supporting load-balancing where members are spread across several Quantum networks in 1.0 would also complicate wiring the LB devices to several networks for each vip. I think once we get the current model working, we can aim to support this in a future release.



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.



Yes you are right, network_id in the LBaaS API means "L3" network_id but for terminology consistency, we should change this to Quantum's "subnet_id" (assuming that a "subnet_id" is unique ID across networks). Same thing would apply to the VIP's "network_id".



Thanks for your code review and feedback!



Youcef



-----Original Message-----
From: Salvatore Orlando [mailto:sorlando at nicira.com]
Sent: Friday, December 07, 2012 4:36 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Quantum] Final Questions on Load Balancing APIs



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



_______________________________________________

OpenStack-dev mailing list

OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121208/20ca714d/attachment.html>


More information about the OpenStack-dev mailing list