<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello again Stephen,<br>
<br>
As usual, responses in-line!<br>
<br>
<br>
<div class="moz-cite-prefix">On 04/17/2014 08:39 PM, Stephen
Balukoff wrote:<br>
</div>
<blockquote
cite="mid:CAAGw+ZrvUv5H8nWzwpidNOFz4TLQi2zVD24bOPWZMjw085SeOQ@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<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 moz-do-not-send="true"
href="mailto:brandon.logan@rackspace.com"
target="_blank">brandon.logan@rackspace.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote">
<div> 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>
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.</div>
</blockquote>
<div><br>
</div>
<div>Noted.</div>
<div> </div>
<blockquote class="gmail_quote">
<div>
<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>
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.
<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>
</div>
</blockquote>
Yes, we assumed that starting from scratch would be the case at
least as far as the API is concerned. <br>
<blockquote
cite="mid:CAAGw+ZrvUv5H8nWzwpidNOFz4TLQi2zVD24bOPWZMjw085SeOQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote">
<div>
<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>
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.</div>
</blockquote>
<div><br>
</div>
<div>Got it. I think we all want to improve the user
experience. </div>
<blockquote class="gmail_quote">
<div>
<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>
<a moz-do-not-send="true"
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. <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">
<div>
<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>
Same data can be derived from the link above.
<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>
</div>
</div>
</div>
</blockquote>
<br>
Yes, most of those features that are in that document for a load
balancer can be done in the single create call.<br>
There is definitely more validation added on for this call. The
roll-back strategy is solid but its really pretty trivial especially
when the code is designed well enough. Thought would have to go
into making the code the best, but I don't see this as a bad thing
at all. I'd prefer the code base be thoroughly thought out and
designed to handle complexities elegantly.<br>
<br>
If the API only allowed primitives, and creating a load balancer in
one call is done through an orchestration layer, that orchestration
layer would then be responsible for rolling back. This could cause
problems because rolling back may involve performing actions that
are not exposed through the API and so the orchestration layer has
no way to do a proper rollback.<br>
<blockquote
cite="mid:CAAGw+ZrvUv5H8nWzwpidNOFz4TLQi2zVD24bOPWZMjw085SeOQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote">
<div>
<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>
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.<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>
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.<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>
</blockquote>
<br>
This is definitely an option as well and gives you the best of both
worlds. As long as there is a way to detach a primitive from the
load balancer, this would be a good option (especially if not doing
the cascading delete can be specified). I do like the idea of it
cleaning up everything for the user, just like German said when a
user leaves it could make life easier for someone. Though, I think
the best option is the one that makes the most sense from an
end-user's perspective, in which case I would need to spend more
time weighing the pros and cons of all three.<br>
<blockquote
cite="mid:CAAGw+ZrvUv5H8nWzwpidNOFz4TLQi2zVD24bOPWZMjw085SeOQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<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
moz-do-not-send="true"
href="mailto:german.eichberger@hp.com" target="_blank">german.eichberger@hp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote">
<div lang="EN-US">
<p class="MsoNormal">
<span>Hi Stephen,</span></p>
<div class="">
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal">1. Could you please explain what
you understand single-call API functionality to be?</p>
</div>
<p class="MsoNormal"><span>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.</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>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> </span></div>
<blockquote class="gmail_quote">
<div lang="EN-US">
<div class="">
<p class="MsoNormal"> </p>
<p class="MsoNormal">2. Could you describe the
simplest use case that uses single-call API in your
environment right now?</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.</p>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal"><span><a moz-do-not-send="true"
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></span></p>
<div class="">
<p class="MsoNormal"><br>
</p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Got it. Looks straight-forward.</div>
<div> </div>
<blockquote class="gmail_quote">
<div lang="EN-US">
<div class="">
<p class="MsoNormal"><span> </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?</p>
<p class="MsoNormal"><span> </span></p>
</div>
<p class="MsoNormal"><span>Yes. If a customer doesn’t
like a load balancer any longer one call will remove
it. This makes a lot of things easier:</span></p>
<p><span>-<span> </span></span><span>GUI
development – one call does it all</span></p>
<p><span>-<span> </span></span><span>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>J</span><span></span></p>
<p><span>-<span> </span></span><span>The
customer can tear down test/dev/etc. load balancer
very quickly</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>
<div><br>
</div>
-- <br>
<span></span>Stephen Balukoff
<br>
Blue Box Group, Inc. <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>