[openstack-dev] [Neutron][LBaaS] dealing with M:N relashionships for Pools and Listeners

Eichberger, German german.eichberger at hp.com
Tue Jun 3 22:40:11 UTC 2014


From deep below in the e-mail chain:
Same here. Cascade-deleting of shared objects should not be allowed in any case.

Being able to delete all lbs and related constructs after a customer leaves and/or for tests is a pretty important requirements for us. It does not necessarily have to be accomplished by a cascading delete on the user api (we could use an admin api for that) but it is important in  our data model to avoid  constraint violation when we want to clean everything out…

I am still with Jorge that sharing of objects in whatever form might confuse customers who will then use up costly customer support time and hence not entirely in the interest of us public cloud providers. The examples with the status is another example for that…


From: Stephen Balukoff [mailto:sbalukoff at bluebox.net]
Sent: Friday, May 30, 2014 9:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] dealing with M:N relashionships for Pools and Listeners

Hi y'all!

Re-responses inline:

On Fri, May 30, 2014 at 8:25 AM, Brandon Logan <brandon.logan at rackspace.com<mailto:brandon.logan at rackspace.com>> wrote:

>         § Where can a user check the success of the update?
> Depending on the object... either the status of the child object
> itself or all of its affected parent(s). Since we're allowing reusing
> of the pool object, when getting the status of a pool, maybe it makes
> sense to produce a list showing the status of all the pool's members,
> as well as the update status of all the listeners using the pool?
This is confusing to me.  Will there be a separate provisioning status
field on the loadbalancer and just a generic status on the child
objects?  I get the idea of a pool having a status the reflects the
state of all of its members.  Is that what you mean by status of a child

It seems to me that we could use the 'generic status' field on the load balancer to show provisioning status as well. :/  Is there a compelling reason we couldn't do this? (Sam?)

And yes, I think that's what I mean with one addition. For example:

If I have Listener A and B which use pool X which has members M and N...  if I set member 'M' to be 'ADMIN_STATE_DISABLED', then what I would expect to see, if I ask for the status of pool X immediately after this change is:
* An array showing N is 'UP' and 'M' is in state 'ADMIN_STATE_DISABLED' and
* An array showing that listeners 'A' and 'B' are in 'PENDING_UPDATE' state (or something similar).

I would also expect listeners 'A' and 'B' to go back to 'UP' state shortly thereafter.

Does this make sense?

Note that there is a problem with my suggestion: What does the status of a member mean when the member is referenced indirectly by several listeners?  (For example, listener A could see member N as being UP, whereas listener B could see member N as being DOWN.)  Should member statuses also be an array from the perspective of each listener? (in other words, we'd have a two-dimensional array here.)

If we do this then perhaps the right thing to do is just list the pool members' statuses in context of the listeners.  In other words, if we're reporting this way, then given the same scenario above, if we set member 'M' to be 'ADMIN_STATE_DISABLED', then asking for the status of pool X immediately after this change is:
* (Possibly?) an array for each listener status showing them as 'PENDING_UPDATE'
* An array for member statuses which contain:
** An array which shows member N is 'UP' for listener 'A' and 'DOWN' for listener 'B'
** An array which shows member M is 'PENDING_DISABLED' for both listener 'A' and 'B'

...and then shortly thereafter we would see member M's status for each listener change to 'DISABLED' at the same time the listeners' statuses change to 'UP'.

So... this second way of looking at it is less intuitive to me, though it is probably more correct. Isn't object re-use fun?

>         ·        Operation status/state – this refers to information
>         returning from the load balancing back end / driver
>         o  How is member status that failed health monitor reflected,
>         on which LBaaS object and how can a user understand the
>         failure?
> Assuming you're not talking about an alert which would be generated by
> a back-end load balancer and get routed to some notification system...
> I think you should be able to get the status of a member by just
> checking the member status directly (ie.  GET /members/[UUID]) or, if
> people like my suggestion above, by checking the status of the pool to
> which the member belongs (ie. GET /pools/[UUID]).
>         ·        Administrator state management
>         o  How is a change in admin_state on member, pool, listener
>         get managed
> I'm thinking that disabling members, pools, and listeners should
> propagate to all parent objects. (For example, disabling a member
> should propagate to all affected pools and listeners, which
> essentially pulls the member out of rotation for all load balancers
> but otherwise leaves listeners and pools up and running. This is
> probably what the user is trying to accomplish by disabling the
> member.)
Are you saying in this case if a member is disabled and all members are
disabled then the parent's pool status is disabled which would then in
turn disable the listener?

No-- I mean that with object re-use, we have only one way to set the admin_state for a shared object, and therefore disabling member 'M' disables it for all connected pools and listeners. I specifically mean that 'admin status' changes of child objects do not affect the 'admin status' of parent objects, though it will (briefly) affect the generic 'status' of the parents as the admin state of the child gets propagated through the connected tree.

Sorry, it's early... clear as mud still? :P

> I do not think it makes sense to propagate to all child objects. For
> example, disabling a listener should not disable all the pools it
> references.
> And by 'propagate' here I mean that config changes are pushed to all
> affected listeners and load balancers-- not that we actually update
> all parents to be 'ADMIN_STATUS_DOWN' or something. Does this make
> sense to you?
Propogating to child objects would be bad with shared listeners and

Sorry, I don't think that's what I'm suggesting. Does my explanation above shed more light on this?

>         o  Do we expect a change in the operation state to reflect
>         this?
> Yes.
>         ·        Statistics consumption
> I actually started another thread on this to get some operator and
> user requirements here, but so far nobody has replied.  FWIW, I'm
> leaning toward having a RESTful interface for statistics that's
> separate from the main configuration interface tree and has implied
> context depending on how it's used.
> For example, if you want to see the stats for a particular member of a
> particular pool of a particular listener on a particular load
> balancer, you'd GET something like the following:
> GET /stats/loadbalancer/LB_UUID/listener/LB_UUID/pool/POOL_UUID/member/MEMBER_UUID
> ...which would give you just the stats for that member in that
> context.
> I think we might also want to support getting overall stats for a
> single logical object. So for example:
> GET /stats/member/MEMBER_UUID
> ...would get you total stats for that member, regardless of which
> pool, listener, or loadbalancer it happens to reside in.
> But... all of this really depends on what users are going to be
> interested in and operators want to provide. What's the point of going
> to the trouble of collecting very specific-context stats if the user
> only cares about aggregate stats?
I know from just a billing standpoint all we care about is just the
loadbalancer stats since a loadbalancer will only have one vip (assuming
we don't do the IPv4 and IPv6).  Those stats would be incoming and
outgoing bandwidth, connections (total and concurrent), and obviously
uptime which will most likely be available through the DB.

We do expose other stats to customers and I am sure our Ops needs other
stats as well.  I'll try to get a full list and respond to your other
email about stats.

I'm not sure how much we would need stats on each individual pool
member, or even the pool.  It is possible our Ops need it though.
However, other operators may need that.

Thanks! I appreciate the input, eh!

>         o  From which object will the user “poll” to get statistics
>         for the different sub objects in the model (ex: load
>         balancer)?
>         o  How can statistics from a shared logical object be obtained
>         in context of the load balancer (ex: pool statistics for a
>         specific listener in a specific load balancer)?
Thats why I think we put only the stats on the loadbalancer resource
(i.e. /loadbalancers/LB_UUID/stats) and that shows the stats for all of
its children entities if we decide to show that.  Alternatively, we
allow the child resource through the load balancer resource
(i.e. /loadbalancers/LB_UUID/listeners/LISTENER_UUID/stats)

Makes sense to me. Makes more sense than what I suggested, too. :)

>         ·        Deletion of shared objects
>         o  Do we support deletion of shared objects that will cascade
>         delete?
I'm not a big fan of cascading deletes on behalf of a customer.  I think
the customer should detach a child object from all of its parents and
then and only then are they able to delete that object.

Same here. Cascade-deleting of shared objects should not be allowed in any case.


Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140603/7a5e69e6/attachment.html>

More information about the OpenStack-dev mailing list