[openstack-dev] [Neutron][LBaaS] Requirements and API revision progress

Stephen Balukoff sbalukoff at bluebox.net
Tue Apr 15 01:20:53 UTC 2014


Hello y'all!

Over the last few months, I feel like we've seen a renewed vigor for
participation in making the LBaaS project successful. After the (still
unresolved) object model discussion started in January, based on feedback
we were getting from Neutron core developers (mainly Mark McClain, from
what I understand) this was followed up by a requirements discussion, a use
cases discussion, and as of the last weekly IRC meeting, I think there are
people in this group now working on proposals for API revision. We've
coordinated this using various documents, and I think the ones that have
carried the most weight are:

* Object model revision summary as started by Eugene:
https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion

(Feedback from core was the 'load balancer' object was an implementation
detail. I think most people on this project don't think so, but it's clear
more work was needed here.)

* Requirements document as started by Jorge:
https://wiki.openstack.org/wiki/Neutron/LBaaS/requirements

(Feedback was that requirements needed to be stated in the form of user or
operator requirements, and not in the form of what a load balancer should
do, per se.)

* Samuel then created this google document to describe several use cases
from the user's point of view:
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?usp=sharing

* And to prioritize what features are needed, Jorge started this document
to collect operator feature usage data (with current load balancer
deployments, presumably outside of OpenStack, since Neutron LBaaS doesn't
presently have many of these features):
https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc&usp=sharing

(Feedback on this is that everyone agrees the legacy API is really
confusing, and that a clean break for the API for Juno is probably prudent,
possibly preserving some backward compatibility with a versioned API.
Further, it was clear we needed an example of what the new API should look
like.)

There are also these proposal documents for L7 and SSL functionality,
presumably on hold until either the API draft being made is closer to
reality, or until we come to an agreement on the required changes to the
object model the proposals imply:
https://wiki.openstack.org/wiki/Neutron/LBaaS/l7
https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL


So! On this front:

1. Does is make sense to keep filling out use cases in Samuel's document
above? I can think of several more use cases that our customers actually
use on our current deployments which aren't considered in the 8 cases in
Samuel's document thus far. Plus nobody has create any use cases from the
cloud operator perspective yet.

2. It looks like we've started to get real-world data on Load Balancer
features in use in the real world. If you've not added your organization's
data, please be sure to do so soon so we can make informed decisions about
product direction. On this front, when will we be making these decisions?

3. Jorge-- I know an action item from the last meeting was to draft a
revision of the API (probably starting from something similar to the Atlas
API). Have you had a chance to get started on this, and are you open for
collaboration on this document at this time? Alternatively, I'd be happy to
take a stab at it this week (though I'm not very familiar with the Atlas
API-- so my proposal might not look all that similar).

What format or template should we be following to create the API
documentation?  (I see this here:
http://docs.openstack.org/api/openstack-network/2.0/content/ch_preface.html
but this seems like it might be a little heavy for an API draft that
is
likely to get altered significantly, especially given how this discussion
has gone thus far. :/ )


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/20140414/6cdf5cc0/attachment.html>


More information about the OpenStack-dev mailing list