Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140530/ead2eb7c/attachment.html>