Open Stack

A couple of questions have come to mind since reading this thread:

1) We are assuming that load balancers can only operate on one update at a
time correct? I.E. We are not allowing multiple updates to occur
concurrently? Whatever the case on this I advocate that we do NOT allow
concurrent modification as complexity of the system increases dramatically
and the gain is very small since load balancers are usually configured
upon create and then rarely updated over their lifetime.

2) It appears that sharing objects is causing complexity to creep in the
deeper the conversations are getting. For example, managing object
statuses seems like a nightmare! That said, does the fundamental rationale
for sharing objects outweigh the simplicity of not sharing objects?

I understand that we've been diligently working on the API revision but I
wanted to take a step back and look at the goal we are trying to solve and
weigh the perceived need for complexity (i.e "flexibility" in the API) vs
a simpler solution.

Cheers,
--Jorge




From:  <Eichberger>, German <german.eichberger at hp.com>
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Date:  Tuesday, June 3, 2014 5:40 PM
To:  "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] [Neutron][LBaaS] dealing with M:N
relashionships for Pools and Listeners


>Hi,
> 
>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Š
> 
>German
> 
>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> 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
>object?
> 
>
>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
>pools.
>
>
> 
>
>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.
>
> 
>
>Thanks,
>
>Stephen
>
>
>
>
> 
>
>-- 
>Stephen Balukoff 
>Blue Box Group, LLC
>(800)613-4305 x807