[openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Brandon Logan brandon.logan at rackspace.com
Wed Apr 23 21:51:16 UTC 2014


Hey Stephen!
Thanks for the proposal and spending time on it (I know it is a large 
time investment).  This is actually very similar in structure to 
something I had started on except a load balancer object was the root 
and it had a one-to-many relationship to VIPs and each VIP had a 
one-to-many relationship to listeners.  We decided to scrap that because 
it became a bit complicated and the concept of sharing VIPs across load 
balancers (single port and protocol this time), accomplished the same 
thing but with a more streamlined API.  The multiple VIPs having 
multiple listeners was the main complexity and your proposal does not 
have that either.

Anyway, some comments and questions on your proposal are listed below.  
Most are minor quibbles, questions and suggestions that can probably be 
fleshed out later when we decide on one proposal and I am going to use 
your object names as terminology.

1. If a VIP can have IPv4 and IPv6 IPs at the same time is that really a 
single VIP? Why not call that a load balancer?  I'm always going to 
advocate for calling the root object a load balancer, and I think even 
in this proposal calling the VIP a load balancer makes sense.  Renaming 
your model's load balancer to something else should be trivial.
2. How would a user be able to add another IPv4 or IPv6 IP to the same VIP?
3. Pool does not have a subnet attribute, how do you define what subnet 
the pool members should be on?
4. In the single create call, how would a user reuse an object that is 
defined inside that request body since they will not have an actual id.
5. I would like to see expanded details of child objects when getting 
the details of an object (i.e. GET /pools shows details of a health monitor)
6. Why is there a protocol on the pool object and the listener object?  
Is this for translating from secure protocols to insecure protocols 
(i.e. HTTPS to HTTP).
7. When returning lists of objects (i.e. GET /vips, GET /pools) I'd like 
to see the name returned as well.
8. Can all primitives be shared among other parent objects belonging to 
the same tenant?
9. can pool members be shared between pools on the same tenant?
    -if so, what happens if two pools are sharing the same pool member, 
one pool has a health monitor, the other does not.  The pool member's 
status will get updated to "DOWN" for both pools.
    -if not, why not just make them children resources of /pools (i.e. 
/pools/{pool_id}/members).

Again, thanks for spending the time on this.  It has a lot of good ideas 
and things we did not think about.  We've been requested to do a POC of 
our proposal, will you and your team be able to do the same?

Thanks,
Brandon


On 04/23/2014 02:15 PM, Stephen Balukoff wrote:
> Hi y'all!
>
> As discussed in last week's IRC meeting, my team members and I have 
> produced a revised draft of the API v2.0 proposal started last week by 
> the Rackspace crew. (Thanks again for this, y'all-- this helped us get 
> a heck of a head start on our revised proposal.)
>
> Our v2.0 API proposal revision can be found here:
> https://docs.google.com/document/d/129Da7zEk5p437_88_IKiQnNuWXzWaS_CpQVm4JBeQnc/edit?usp=sharing
>
> (I've enabled commenting on the above google doc, but for longer 
> discussion of fundamental issues, let's keep that to this mailing 
> list, eh!)
>
> Please also pay attention to the Introduction section of this 
> document:  I've defined which glossary of terms we're using there and 
> provided links to a proposed corresponding object model diagram and 
> its source. Further, I've pointed out decisions we made drafting this 
> API as well as issues not yet addressed. I would appreciate your 
> feedback on all of this (again, the discussions for which should 
> probably happen on this mailing list).
>
> To get to some of the points I know a lot of people will be interested in:
>
>   * This proposal does include a single-call interface for both
>     creation and deletion, and yes, all primitives can be created
>     through it.
>   * This proposal does include L7 functionality support, based
>     somewhat loosely on the ideas represented here:
>     https://wiki.openstack.org/wiki/Neutron/LBaaS/l7
>   * This proposal does include SSL termination and re-encryption
>     support, based loosely both on what we already do in our
>     envionment, as well as this:
>     https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL
>   * We have also tried to keep in mind features in use and requested
>     in the following two documents as well:
>     https://wiki.openstack.org/wiki/Neutron/LBaaS/requirements
>     https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc&usp=sharing
>   * HA functionality is not addressed in this document, per se, other
>     than expressing the conviction that however this is handled will
>     probably not affect the user API expressed in this document. (We
>     have an ongoing discussion about this going on in another mailing
>     list thread-- and now that I'm not neck deep in API documentation
>     I'll probably jump back onto this in the next couple of days.)
>
> And... I think that's about it. Please have fun ripping this draft to 
> shreds!
>
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140423/698404bf/attachment.html>


More information about the OpenStack-dev mailing list