Open Stack

Hi Sam and Stephen,

On Thu, 2014-05-29 at 21:10 -0700, Stephen Balukoff wrote:
> 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.
I agree with this as well.
> 
> 
>  
>         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?

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?

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

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

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

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

>         
>         
> 
> 
> Thanks,
> Stephen 
> 
> 
> -- 
> Stephen Balukoff 
> Blue Box Group, LLC 
> (800)613-4305 x807
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev