<div dir="ltr">Hello German and Brandon!<div><br></div><div>Responses in-line:</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 17, 2014 at 3:46 PM, Brandon Logan <span dir="ltr"><<a href="mailto:brandon.logan@rackspace.com" target="_blank">brandon.logan@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Stephen,<br>
I have responded to your questions below.<div class=""><br>
<div><br>
On 04/17/2014 01:02 PM, Stephen Balukoff wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Howdy folks!</div>
<div><br>
</div>
<div>Based on this morning's IRC meeting, it seems to me there's
some contention and confusion over the need for "single call"
functionality for load balanced services in the new API being
discussed. This is what I understand:</div>
<div><br>
</div>
<div>* Those advocating "single call" are arguing that this
simplifies the API for users, and that it more closely
reflects the users' experience with other load balancing
products. They don't want to see this functionality
necessarily delegated to an orchestration layer (Heat),
because coordinating how this works across two OpenStack
projects is unlikely to see success (ie. it's hard enough
making progress with just one project). I get the impression
that people advocating for this feel that their current users
would not likely make the leap to Neutron LBaaS unless some
kind of functionality or workflow is preserved that is no more
complicated than what they currently have to do.</div>
</div>
</blockquote>
</div><font color="#ff0000">Another reason, which I've mentioned many
times before and keeps getting ignored, is because the more
primitives you add the longer it will take to provision a load
balancer. Even if we relied on the orchestration layer to build
out all the primitives, it still will take much more time to
provision a load balancer than a single create call provided by
the API. Each request and response has an inherent time to
process. Many primitives will also have an inherent build time.
Combine this in an environment that becomes more and more dense,
build times will become very unfriendly to end users whether they
are using the API directly, going through a UI, or going through
an orchestration layer. This industry is always trying to improve
build/provisioning times and there are no reasons why we shouldn't
try to achieve the same goal.</font></div></blockquote><div><br></div><div>Noted.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class=""><blockquote type="cite">
<div dir="ltr">
<div>* Those (mostly) against the idea are interested in seeing
the API provide primitives and delegating "higher level"
single-call stuff to Heat or some other orchestration layer.
There was also the implication that if "single-call" is
supported, it ought to support both simple and advanced
set-ups in that single call. Further, I sense concern that if
there are multiple ways to accomplish the same thing supported
in the API, this redundancy breeds complication as more
features are added, and in developing test coverage. And
existing Neutron APIs tend to expose only primitives. I get
the impression that people against the idea could be convinced
if more compelling reasons were illustrated for supporting
single-call, perhaps other than "we don't want to change the
way it's done in our environment right now."</div>
</div>
</blockquote>
</div><font color="#ff0000">I completely disagree with "we dont want to
change the way it's done in our environment right now". Our
proposal has changed the way our current API works right now. We
do not have the notion of primitives in our current API and our
proposal included the ability to construct a load balancer with
primitives individually. We kept that in so that those operators
and users who do like constructing a load balancer that way can
continue doing so. What we are asking for is to keep our users
happy when we do deploy this in a production environment and
maintain a single create load balancer API call.</font><div class=""><br></div></div></blockquote><div><br></div><div>There's certainly something to be said for having a less-disruptive user experience. And after all, what we've been discussing is so radical a change that it's close to starting over from scratch in many ways.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="">
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>I've mostly stayed out of this debate because our solution
as used by our customers presently isn't "single-call" and I
don't really understand the requirements around this.</div>
<div><br>
</div>
<div>So! I would love it if some of you could fill me in on
this, especially since I'm working on a revision of the
proposed API. Specifically, what I'm looking for is answers to
the following questions:</div>
<div><br>
</div>
<div>1. Could you please explain what you understand single-call
API functionality to be?</div>
</div>
</blockquote>
</div><font color="#cc0000">Single-call API functionality is a call that
supports adding multiple features to an entity (load balancer in
this case) in one API request. Whether this supports all features
of a load balancer or a subset is up for debate. I prefer all
features to be supported. Yes it adds complexity, but complexity
is always introduced by improving the end user experience and I
hope a good user experience is a goal.</font></div></blockquote><div><br></div><div>Got it. I think we all want to improve the user experience. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="">
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>2. Could you describe the simplest use case that uses
single-call API in your environment right now? Please be very
specific-- ideally, a couple examples of specific CLI
commands a user might run, or API (along with specific
configuration data) would be great.</div>
</div>
</blockquote>
</div><font color="#cc0000"><a href="http://docs.rackspace.com/loadbalancers/api/v1.0/clb-devguide/content/Create_Load_Balancer-d1e1635.html" target="_blank">http://docs.rackspace.com/loadbalancers/api/v1.0/clb-devguide/content/Create_Load_Balancer-d1e1635.html</a><br>
<br>
This page has many different ways to configure a load balancer
with one call. It ranges from a simple load balancer to a load
balancer with a much more complicated configuration. Generally,
if any of those features are allowed on a load balancer then it is
supported through the single call. </font><br><div class="">
<blockquote type="cite">
<div dir="ltr">
<div><br></div></div></blockquote></div></div></blockquote><div>I'm going to use example 4.10 as the "simplest" case I'm seeing there. (Also because I severely dislike XML ;) )</div><div><br></div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="">
<blockquote type="cite"><div dir="ltr"><div>
</div>
<div>3. Could you describe the most complicated use case that
your single-call API supports? Again, please be very specific
here.</div>
</div>
</blockquote>
</div><font color="#cc0000">Same data can be derived from the link above.</font><div class=""><br></div></div></blockquote><div><br></div><div>Ok, I'm actually not seeing and complicated examples, but I'm guessing that any attributes at the top of the page could be expanded on according the the syntax described.</div>
<div><br></div><div>Hmmm... one of the draw-backs I see with a "one-call" approach is you've got to have really good syntax checking for everything right from the start, or (if you plan to handle primitives one at a time) a really solid roll-back strategy if anything fails or has problems, cleaning up any primitives that might already have been created before the whole call completes.</div>
<div><br></div><div>The alternative is to not do this with primitives... but then I don't see how that's possible either. (And certainly not easy to write tests for: The great thing about small primitives is their methods tend to be easier to unit test.)</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="">
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>4. What percentage of your customer base are used to using
single-call functionality, and what percentage are used to
manipulating primitives?</div>
</div>
</blockquote>
</div><font color="#cc0000">100% but just like others it is the only way
to create a load balancer in our API. So this data doesn't mean
much.</font><br>
<br>
Oh! One other question:
<div><br>
</div>
<div><div class=""> 5. Should "single-call" stuff work for the lifecycle of a
load balancing service? That is to say, should "delete"
functionality also clean up all primitives associated with the
service?<br>
<br>
</div><font color="#ff0000">How we were thinking was that it would just
"detach" the primitives from the load balancer but keep them
available for association with another load balancer. A user
would only be able to actually delete a primitive if it went
through the root primitive resource (i.e. /pools, /vips).
However, this is definitely up for debate and there are pros and
cons to doing it both ways. If the system completely deletes
the primitives on the deletion of the load balancer, then the
system has to handle when one of those primitives is being
shared with another load balancer.</font><br>
</div>
<br></div></blockquote><div><br></div><div>That makes sense-- but I think it could end in disaster for the poor fool who isn't aware of that and makes "deploying load balancing services" part of their continuous integration run. In very little time, they'd have bazillions of abandoned primitives. At the same time, it doesn't make sense to delete shared primitives, lest you horribly break things for service B by nuking service A.</div>
<div><br></div><div>So, going with the principle of least surprise here, it seems to me that most people attempting a delete in a single call are going to want all the non-shared primitives deleted (in a cascading effect) unless they specify that they want the primitives preserved. It would be great if there were a good way to set this as an option somehow (though I know an HTTP DELETE doesn't allow for this kind of flexibility-- maybe something appended to the URI if you want to preserve non-shared primitives?)</div>
</div><br>Deleting a primitive (ie. not using single-call) should clearly just delete the primitive. Though, of course, it would be nice to specify (using some flag) that the delete should be ignored if the primitive happens to be shared.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 17, 2014 at 2:23 PM, Eichberger, German <span dir="ltr"><<a href="mailto:german.eichberger@hp.com" target="_blank">german.eichberger@hp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><p class="MsoNormal">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Hi Stephen,<u></u><u></u></span></p><div class=""><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal">1. Could you please explain what you understand single-call API functionality to be?<u></u><u></u></p></div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">From my perspective most of our users will likely create load balancers via a web interface. Thought not necessary, having a single API call makes it easier to develop the web interface.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">For the “expert” users I envision them to create a load balancer, tweak with the settings, and when they arrive at the load balancer they need to automate the creation of it. So if they have to create several objects with multiple calls in a particular order that is far too complicated and makes the learning curve very steep from the GUI to the API. Hence, I like being able to do one call and get a functioning load balancer. I like that aspect from Jorge’s proposal. On the other hand making a single API call contain all possible settings might make it too complex for the casual user who just wants some feature activated the GUI doesn’t provide….</span> </p>
</div></blockquote><div><br></div><div>That makes sense. Are you envisioning having a function in the GUI to "show me the CLI or API command to do this" once a user has ticked all the check-boxes they want and filled in the fields they want?</div>
<div><br></div><div>For our power users-- I could see some of them occasionally updating primitives. Probably the most common API command we see has to do with users who have written their own scaling algorithms which add and remove members from a pool as they see load on their app servers change throughout the day (and spin up / shut down app server clones in response).</div>
<div> <span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> </span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple"><div class=""><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">2. Could you describe the simplest use case that uses single-call API in your environment right now?<u></u><u></u></p>
<p class="MsoNormal">Please be very specific-- ideally, a couple examples of specific CLI commands a user might run, or API (along with specific configuration data) would be great.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p>
</div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><a href="http://libra.readthedocs.org/en/latest/api/rest/load-balancer.html#create-a-new-load-balancer" target="_blank">http://libra.readthedocs.org/en/latest/api/rest/load-balancer.html#create-a-new-load-balancer</a><u></u><u></u></span></p>
<div class=""><p class="MsoNormal"><u></u><br></p></div></div></blockquote><div><br></div><div>Got it. Looks straight-forward.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple"><div class=""><p class="MsoNormal"></p></div><div class=""><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal">5. Should "single-call" stuff work for the lifecycle of a load balancing service? That is to say, should "delete" functionality also clean up all primitives associated with the service?<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p></div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Yes. If a customer doesn’t like a load balancer any longer one call will remove it. This makes a lot of things easier:<u></u><u></u></span></p>
<p><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">-<span style="font-size:7pt;font-family:'Times New Roman'"> </span></span><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">GUI development – one call does it all<u></u><u></u></span></p>
<p><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">-<span style="font-size:7pt;font-family:'Times New Roman'"> </span></span><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Cleanup scripts: If a customer leaves us we just need to run delete on a list of load balancers – ideally if the API had a call to delete all load balancers of a specific user/project that would be even better </span><span style="font-size:11pt;font-family:Wingdings;color:rgb(31,73,125)">J</span><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p>
<p><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">-<span style="font-size:7pt;font-family:'Times New Roman'"> </span></span><u></u><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">The customer can tear down test/dev/etc. load balancer very quickly<u></u><u></u></span></p>
<p><br></p></div></blockquote><div>What do you think of my "conditional cascading delete" idea (ie. nuke everything but shared primitives) above for the usual / least surprise case?</div><div><br></div><div> </div>
<div>Thanks,</div><div>Stephen</div></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, Inc. <br>(800)613-4305 x807
</div></div>