Open Stack

Hi Salvatore and Youcef,

I added more comments inline…



Thanks

Leon

发件人: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com]
发送时间: 2012年12月7日 18:31
收件人: OpenStack Development Mailing List
主题: Re: [openstack-dev] [Quantum][LBaaS] Final Questions on Load
Balancing APIs



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.



[leon] I suggest that we decouple pool and member status from mgmt.
perspective.  This is different from health status where the health_status
of pool is aggregation of member health_status.



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.

[Leon] Current lbaas DB will provide method to update the resource state
(from pending to done). The plugin is responsible for moving the status
according to the interaction with driver.  For instance, in create_vip
call, the plugin first write db with pending_create state, then call
driver to do real configuration (could be either sync or async), finally
update the resource to created or error.



It’s same for delete operation.  I need to update code a bit that a
delete call should first update resource status to pending_delete status,
then call driver to do real action, finally remove from DB.



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.



[Leon] As Youcef said, this is simple for plugin so that we don’t need to
pending the operations. But I’d say that we should follow the common
practice across the whole quantum plugins.  How other plugins handle this?



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.



[Leon] I tend to agree with Youcef.  The most important thing is to
deliver the 1st release even the use scenario is limited, then we can
progress it on top of it.



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



[Leon] Youcef, do you mean we should change all “nework_id” in current
Lbaas API resources to subnet_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

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

 <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
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/20121207/3527a962/attachment.html>