Open Stack

Hello,

I've been going through the 40+ use cases, and I couldn't help but
notice some additions that are either unclear or not descriptive.

For ease of reference, I'll link the document: 
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit#

I took a look at most of them in a high-level thought process to use for
evaluation in feasibility for the Rackspace API proposal, and began
documenting them for purpose of comparison.  However, I've run into some
issues understanding and/or evaluating them.

One section of the use-cases come to mind specifically.  Numbers 31
through 39 are not very descriptive.  Many of these don't seem like
use-cases as much as they seem like feature requests.  Ideally there
would be more information, or an example of a problem to solve including
the use-case, similar to many of the others.

On that same note, there are some use-cases I simply don't understand,
be-it my own naivety, or wording in the use-case.

Use-Case 10:  I assumed this was referring to the source-IP that
accesses the Load Balancer.  As far as I know the X-Forwarded-For header
includes this.  To satisfy this use-case, was there some expectation to
retrieve this information through an API request?  Also, with the
trusted-proxy evaluation, is that being handled by the pool member, or
was this in reference to an "access list" so-to-speak defined on the
load balancer?

Use-Case 20:  I do not believe much of this is handled within the LBaaS
API, but with a different service that provides auto-scaling
functionality.  Especially the "on-the-fly" updating of properties.
This also becomes incredibly difficult when considering TCP session
persistence when the possible pool member could be removed at any
automated time.

Use-Case 25:  I think this one is referring to the functionality of a
"draining" status for a pool member; the pool member will not receive
any new connections, and will not force any active connection closed.
Is that the right way to understand that use-case?

Use-Case 26:  Is this functionally wanting something like an "error
page" to come up during the maintenance window?  Also, to accept only
connections from a specific set of IPs only during the maintenance
window, one would manually have to create an access list for the load
balancer during the time for testing, and then either modify or remove
it after maintenance is complete.  Does this sound like an accurate
understanding/solution?

Use-Case 37:  I'm not entirely sure what this one would mean.  I know I
included it in the section that sounded more like features, but I was
still curious what this one referred to.  Does this have to do with the
desire for auto-scaling?  When a pool member gains a certain threshold
of connections another pool member is created or chosen to handle the
next connection(s) as they come?

Please feel free to correct me anywhere I've blundered here, and if my
proposed "solution" is inaccurate or not easily understood, I'd be more
than happy to explain in further detail.  Thanks for any help you can
offer!

-Trevor Vardeman