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@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
