<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hey Stephen!<br>
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.<br>
<br>
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.<br>
<br>
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. <br>
2. How would a user be able to add another IPv4 or IPv6 IP to the
same VIP?<br>
3. Pool does not have a subnet attribute, how do you define what
subnet the pool members should be on?<br>
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.<br>
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)<br>
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).<br>
7. When returning lists of objects (i.e. GET /vips, GET /pools) I'd
like to see the name returned as well.<br>
8. Can all primitives be shared among other parent objects belonging
to the same tenant?<br>
9. can pool members be shared between pools on the same tenant? <br>
-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.<br>
-if not, why not just make them children resources of /pools
(i.e. /pools/{pool_id}/members).<br>
<br>
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?<br>
<br>
Thanks,<br>
Brandon<br>
<br>
<br>
<div class="moz-cite-prefix">On 04/23/2014 02:15 PM, Stephen
Balukoff wrote:<br>
</div>
<blockquote
cite="mid:CAAGw+ZqfH5gAsJv7QpWYkKv=gY+fXZ095OMbe1PienFKqs-GVg@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Hi y'all!</div>
<div><br>
</div>
<div>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.)</div>
<div><br>
</div>
<div>Our v2.0 API proposal revision can be found here:</div>
<div><a moz-do-not-send="true"
href="https://docs.google.com/document/d/129Da7zEk5p437_88_IKiQnNuWXzWaS_CpQVm4JBeQnc/edit?usp=sharing">https://docs.google.com/document/d/129Da7zEk5p437_88_IKiQnNuWXzWaS_CpQVm4JBeQnc/edit?usp=sharing</a><br>
</div>
<div><br>
</div>
<div>(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!)</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>To get to some of the points I know a lot of people will be
interested in:</div>
<div>
<ul>
<li>This proposal does include a single-call interface for
both creation and deletion, and yes, all primitives can be
created through it.<br>
</li>
<li>This proposal does include L7 functionality support,
based somewhat loosely on the ideas represented here: <a
moz-do-not-send="true"
href="https://wiki.openstack.org/wiki/Neutron/LBaaS/l7">https://wiki.openstack.org/wiki/Neutron/LBaaS/l7</a><br>
</li>
<li>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: <a
moz-do-not-send="true"
href="https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL">https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL</a><br>
</li>
<li>We have also tried to keep in mind features in use and
requested in the following two documents as well: <a
moz-do-not-send="true"
href="https://wiki.openstack.org/wiki/Neutron/LBaaS/requirements">https://wiki.openstack.org/wiki/Neutron/LBaaS/requirements</a>
<a moz-do-not-send="true"
href="https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc&usp=sharing">https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc&usp=sharing</a><br>
</li>
<li>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.)</li>
</ul>
</div>
<div>And... I think that's about it. Please have fun ripping
this draft to shreds!</div>
<div><br>
</div>
Thanks,
<div>Stephen<br>
<div><br>
</div>
-- <br>
<span></span>Stephen Balukoff
<br>
Blue Box Group, LLC
<br>
(800)613-4305 x807
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>