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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
