Open Stack

Hi Sam,

Here are my thoughts on this:


On Thu, May 29, 2014 at 12:32 PM, Samuel Bercovici <SamuelB at radware.com>
wrote:

>  Before solving everything, I would like first to itemize the things we
> should solve/consider.
>
> So pleas focus first on what is it that we need to pay attention for and
> less on how to solve such issues.
>
>
>
> Follows the list of items:
>
> ·         Provisioning status/state
>
> o   Should it only be on the loadblancer?
>
That makes sense to me, unless we're also using this field to indicate a
pending change from an update as well. Pending changes here should be
reflected in the listener state.



>  o   Do we need a more granular status per logical child object?
>

Than what? I'm not sure I understand what you're saying here. Can you give
a couple examples?


>  o   Update process
>
> §  What happens when a logical child object is modified?
>
Any affected parent objects should show a 'PENDING_UPDATE' status or
something similar until the change is pushed to them.


>  §  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?


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

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?


>  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?


>  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)?
>
 ·         Deletion of shared objects
>
> o   Do we support deletion of shared objects that will cascade delete?
>
>
>
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/20140529/cf602a05/attachment.html>