On Apr 14, 2014, at 8:20 PM, Stephen Balukoff <sbaluk...@bluebox.net<mailto:sbaluk...@bluebox.net>> wrote:
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. We have been using the document when discussing our API proposal. The use cases had some surprising implications for our api proposal which we had to rethink. Particularly the L7 URL routing use case #7 As far as operator requirements I know our team is advocating a management API that is separate from the public api (Separate meaning regular users can reach its endpoint) but still apart of the CORE codebase. 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? Would it be prudent to make these decisions at the Atlanta summit or thereafter. 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). Our team, (Jorge's team) are investigating the API from the perspective of supporting Single Loadbalancer creation calls that is still compatible with the ability to create separate components such as vips pools ssl confs and lasteltly making a call that joins them to a loadbalancer. We wanted to iron out some of the gotcha's we've been encountering before we presented the proposals. Most recently we are looking at how allowing inplace object creation which Im calling "literals" vs the ability to create parent objects with the ids of previously created objects. I'll let brandon logan follow uo on this later on today. We are still in meetings right now about the API. |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. :/ ) For the draft I'm sure we don't need it just yet but our own CLB1.0 implementation follows that same docbook format so we at rackspace intend it for our own documentation we issue to customers. http://docs.rackspace.com/loadbalancers/api/v1.0/clb-devguide/content/Overview-d1e82.html Thanks, Stephen -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
