Stephen,
I have responded to your questions below.
On 04/17/2014 01:02 PM, Stephen Balukoff wrote:
Howdy folks!
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:
* 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.
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.
* 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."
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.
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.
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:
1. Could you please explain what you understand single-call API
functionality to be?
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.
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.
http://docs.rackspace.com/loadbalancers/api/v1.0/clb-devguide/content/Create_Load_Balancer-d1e1635.html
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.
3. Could you describe the most complicated use case that your
single-call API supports? Again, please be very specific here.
Same data can be derived from the link above.
4. What percentage of your customer base are used to using single-call
functionality, and what percentage are used to manipulating primitives?
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.
Oh! One other question:
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?
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.
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
