Open Stack

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140417/73772b91/attachment.html>