Re: [openstack-dev] [Neutron][LBaas] "Single call" API discussion

[Eugene Nikanorov]

Hi Brandon,


On Tue, Apr 22, 2014 at 6:58 AM, Brandon Logan
wrote:

> Hello Eugene!
>
> Are you talking about seeing the code in a simplified approach for a
> single create call using the current API objects, or one that uses
> objects created based on the proposal?
>
I'm talking about actually implementing single-call API within existing
code (LBaaS plugin)
Let's see what it takes. It obviously should not account for each end every
case we have in mind,
but at least it should allow existing functionality (single vip, single
pool).


> I was experimenting over the weekend on getting a single create call in
> the current API model.  I was able to implement it pretty easy but did
> run into some issues.  Now, since this was just a quick test, and to
> save time I did not implement it the correct way, only a way in which it
> accepted a single create call and did everything else the usual way.  If
> it were actually a blueprint and up for a merge I would have done it the
> proper way (and with everyone else's input).  If you want to see that
> code let me know, its just on a branch of a fork.  Nothing really much
> to see though, implemented in the easiest way possible.  For what its
> worth though, it did speed up the creation of an actual load balancer by
> 75% on average.
>
I'd prefer to see such patch on gerrit.



>
> The current way to define an extension's resources and objects is using
> a dictionary that defines the resource, object expected for POSTs and
> PUTs, and plugin methods to be implemented.  This dictionary is passed
> to the neutron API controller that does validation, defaulting, and
> checks if an attribute of an object is required and if it can be changed
> on posts and puts.  This currently does not support defaults for 2nd
> level nested dictionary objects, and doesn't support validation,
> defaulting, or required attributes for any nesting level after the
> 2nd.
>
> This can easily be added in obviously (smells like recursion will come
> in handy),

That also smells like a bit of generic work for Neutron Extension Framework.
It has limited support for 2nd level resources right now.

but it should be noted that just the resource and API object
> schema definitions for what we need for a single create call are not
> supported right now.
>
> Maybe there's some way to allow the extensions to define their own
> validation for their own resources and objects.  That's probably another
> topic for another day, though.
>

Yes, I think most extensions provide both additional resources and
additional validation methods.

Thanks,
Eugene.


> On Fri, 2014-04-18 at 17:53 +0400, Eugene Nikanorov wrote:
> > > 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.
> >
> >
> >
> >
> > 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.
> >
> >
> > 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.
> >
> >
> > 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.)
> >
> > These are the good arguments! That's why I'd like to actually see the
> > code (even simplified approach will could work as a first step), i
> > thing it could do a lot of things clearer.
> >
> >
> > Thanks,
> > Eugene.
> > ___
> > 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
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaas] "Single call" API discussion

[Brandon Logan]

Hello Eugene!

Are you talking about seeing the code in a simplified approach for a
single create call using the current API objects, or one that uses
objects created based on the proposal?

I was experimenting over the weekend on getting a single create call in
the current API model.  I was able to implement it pretty easy but did
run into some issues.  Now, since this was just a quick test, and to
save time I did not implement it the correct way, only a way in which it
accepted a single create call and did everything else the usual way.  If
it were actually a blueprint and up for a merge I would have done it the
proper way (and with everyone else's input).  If you want to see that
code let me know, its just on a branch of a fork.  Nothing really much
to see though, implemented in the easiest way possible.  For what its
worth though, it did speed up the creation of an actual load balancer by
75% on average.

The current way to define an extension's resources and objects is using
a dictionary that defines the resource, object expected for POSTs and
PUTs, and plugin methods to be implemented.  This dictionary is passed
to the neutron API controller that does validation, defaulting, and
checks if an attribute of an object is required and if it can be changed
on posts and puts.  This currently does not support defaults for 2nd
level nested dictionary objects, and doesn't support validation,
defaulting, or required attributes for any nesting level after the
2nd.  

This can easily be added in obviously (smells like recursion will come
in handy), but it should be noted that just the resource and API object
schema definitions for what we need for a single create call are not
supported right now.

Maybe there's some way to allow the extensions to define their own
validation for their own resources and objects.  That's probably another
topic for another day, though.

On Fri, 2014-04-18 at 17:53 +0400, Eugene Nikanorov wrote:
> > 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.
> 
> 
> 
> 
> 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.
> 
> 
> 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.
> 
> 
> 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.)
>  
> These are the good arguments! That's why I'd like to actually see the
> code (even simplified approach will could work as a first step), i
> thing it could do a lot of things clearer.
> 
> 
> Thanks,
> Eugene.
> ___
> 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

Re: [openstack-dev] [Neutron][LBaas] "Single call" API discussion

[Stephen Balukoff]

Hi y'all!

Yes-- I agree that is a very bad idea to delete a primitive that's being
shared by other load balancing configurations. The only case where this
seems acceptable to me is the case that German mentioned where all assets
on a given user's account are being wrapped up. But even in this case,
assuming each load balancing service is being deleted from the root level,
eventually none of the primitives will be shared anymore...

In fact, what do y'all think of this policy?  If a primitive is shared at
all, an attempt to delete it directly should return an error indicating
it's still in use.

Also, I've been making this assumption the whole time, but it's probably
worth mentioning: I'm assuming primitives cannot be shared among tenants.
(It seems to me that we'd be opening up a whole nasty can of worms
security-wise if we allowed tenants to share primitives.)

Here's an alternate idea for handling the case of abandoned primitives
suggested by my team-mate Dustin Lundquist:

Instead of doing any kind of cascading delete when a root object gets
deleted, follow Brandon's idea and simply detach the primitives from the
object being deleted. Later, a periodic garbage-collection process goes
through and removes any orphaned primitives a reasonable interval after it
was orphaned (this interval could be configurable per operator, per tenant,
per user... whatever). If we do this:

* Each primitive would need an additional 'orphaned_at' attribute
* Primitives (other than the root object) created outside of a single-call
interface would be created in an orphaned state.
* Viewing the attributes of a primitive should also show whether it's an
orphan, and if so, when the garbage collector will delete it.
* Update and creation tasks that reference any connected primitives would
clear the above orphaned_at attributes of said primitives
* Deletion tasks would need to check connected primitives and update their
orphaned_at attribute if said deletion orphans the primitive (ie. do an
immediate reference check, set orphaned_at if references = 0)
* It probably also makes sense to allow some primitives to have a flag set
by the user to prevent garbage collection from ever cleaning them up (ex.
SSL certificates are probably a good candidate for this). Maybe a "persist"
boolean attribute or something?
* Garbage collection never cleans up root objects.

It seems to me the above:
* Would prevent the CI user from having a bazillion orphaned primitives.
* Does not immediately nuke anything the customer wasn't planning on nuking
* Probably follows the principle of least surprise a little better than my
previous "conditional cascading delete" suggestion
* Still allows the simple act of deleting all the root objects to
eventually delete all primitives on an account (ie. the "delete this
account" task German was talking about.)
* Has a secondary side-benefit of not immediately destroying all the
supporting primitives of an object if the user accidentally nukes the wrong
object.

Also, it may be appropriate for some primitives to skip the garbage
collection process and simply get deleted when their immediate parent
primitive is deleted. This applies to primitives that aren't allowed to be
shared, like:
* Members (ie, deleting a pool deletes all its members, immediately)
* "join" objects, like the 'rule' object that associates a listener with a
non-default pool in the case of L7 switching

I still like the idea of also having a cascading delete of some kind, in
case the user wants to see all the primitives go away immediately (though
they could always step through these themselves), or, again, as an
immediate way to ensure all objects associated with a customer account are
cleaned up quickly when the account is deleted. Though, I'm also thinking
this should be an explicit flag the user has to set. (And again, even with
this flag set, shared primitives are not deleted.)

What do y'all think of the above idea?

Thanks,
Stephen



On Fri, Apr 18, 2014 at 2:35 PM, Carlos Garza wrote:

>
>  On Apr 17, 2014, at 8:39 PM, Stephen Balukoff 
>  wrote:
>
>  Hello German and Brandon!
>
>  Responses in-line:
>
>
> On Thu, Apr 17, 2014 at 3:46 PM, Brandon Logan <
> brandon.lo...@rackspace.com> wrote:
>
>> 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 (i

Re: [openstack-dev] [Neutron][LBaas] "Single call" API discussion

[Carlos Garza]

On Apr 17, 2014, at 8:39 PM, Stephen Balukoff 
mailto:sbaluk...@bluebox.net>>
 wrote:

Hello German and Brandon!

Responses in-line:


On Thu, Apr 17, 2014 at 3:46 PM, Brandon Logan 
mailto:brandon.lo...@rackspace.com>> wrote:
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.

Noted.

* 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.


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.


Its not disruptive. There is nothing preventing them from continuing to use 
 the multiple primitive operations philosophy, so they can continue that 
approach.


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.

Got it. I think we all want to improve the user experience.

2. Could you describe the simplest use case that uses single-call API in your 
environment right now? Please be very sp

Re: [openstack-dev] [Neutron][LBaas] "Single call" API discussion

[Eugene Nikanorov]

>
>
>  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.
>
> Yes, we assumed that starting from scratch would be the case at least as
> far as the API is concerned.
>

We're going to evolve, folks, not start everything over.
Any 'radical change' need to prove it works for everyone. The only viable
option for that is to implement and see.

Thanks,
Eugene.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaas] "Single call" API discussion

[Eugene Nikanorov]

>
> 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.
>>
>>
> 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.
>
> 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.
>
> 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.)
>

These are the good arguments! That's why I'd like to actually see the code
(even simplified approach will could work as a first step), i thing it
could do a lot of things clearer.

Thanks,
Eugene.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaas] "Single call" API discussion

[Brandon Logan]

Hello again Stephen,

As usual, responses in-line!


On 04/17/2014 08:39 PM, Stephen Balukoff wrote:

Hello German and Brandon!

Responses in-line:


On Thu, Apr 17, 2014 at 3:46 PM, Brandon Logan 
mailto:brandon.lo...@rackspace.com>> wrote:


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.


Noted.


* 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.


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.
Yes, we assumed that starting from scratch would be the case at least as 
far as the API is concerned.




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 experie

Re: [openstack-dev] [Neutron][LBaas] "Single call" API discussion

[Stephen Balukoff]

Hello German and Brandon!

Responses in-line:


On Thu, Apr 17, 2014 at 3:46 PM, Brandon Logan
wrote:

>  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.
>

Noted.


>  * 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.
>
>
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.


>
>  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.
>

Got it. I think we all want to improve the user experience.

>
>  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.

Re: [openstack-dev] [Neutron][LBaas] "Single call" API discussion

[Brandon Logan]

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 speci

Re: [openstack-dev] [Neutron][LBaas] "Single call" API discussion

[Carlos Garza]

On Apr 17, 2014, at 2:11 PM, Stephen Balukoff 
mailto:sbaluk...@bluebox.net>>
 wrote:

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?


We were advocating leaving the primitives behind for the user to delete out 
of respect for shared objects.
The proposal mentions this too.


On Thu, Apr 17, 2014 at 11:44 AM, Stephen Balukoff 
mailto:sbaluk...@bluebox.net>> wrote:
Hi Sri,

Yes, the meeting minutes & etc. are all available here, usually a few minutes 
after the meeting is over:  
http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/

(You are also, of course, welcome to join!)

Stephen


On Thu, Apr 17, 2014 at 11:34 AM, Sri 
mailto:sri.networ...@gmail.com>> wrote:
hello Stephen,


I am interested in LBaaS and want to know if we post the weekly meeting's
chat transcripts online?
or may be update an etherpad?


Can you please share the links?

thanks,
SriD



--
View this message in context: 
http://openstack.10931.n7.nabble.com/Neutron-LBaas-Single-call-API-discussion-tp38533p38542.html
Sent from the Developer mailing list archive at Nabble.com.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807



--
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

Re: [openstack-dev] [Neutron][LBaas] "Single call" API discussion

[Eichberger, German]

Hi Stephen,

1. Could you please explain what you understand single-call API functionality 
to be?
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.

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….


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://libra.readthedocs.org/en/latest/api/rest/load-balancer.html#create-a-new-load-balancer

3. Could you describe the most complicated use case that your single-call API 
supports? Again, please be very specific here.

Our API doesn’t have that many features so calls don’t get complicated.

4. What percentage of your customer base are used to using single-call 
functionality, and what percentage are used to manipulating primitives?

We only offer the single call to create a load balancer so 100% of our 
customers use it. (So this is not a good number)

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?

Yes. If a customer doesn’t like a load balancer any longer one call will remove 
it. This makes a lot of things easier:

-  GUI development – one call does it all

-  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 ☺

-  The customer can tear down test/dev/etc. load balancer very quickly


German

From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Thursday, April 17, 2014 12:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaas] "Single call" API discussion

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?

On Thu, Apr 17, 2014 at 11:44 AM, Stephen Balukoff 
mailto:sbaluk...@bluebox.net>> wrote:
Hi Sri,

Yes, the meeting minutes & etc. are all available here, usually a few minutes 
after the meeting is over:  
http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/

(You are also, of course, welcome to join!)

Stephen

On Thu, Apr 17, 2014 at 11:34 AM, Sri 
mailto:sri.networ...@gmail.com>> wrote:
hello Stephen,


I am interested in LBaaS and want to know if we post the weekly meeting's
chat transcripts online?
or may be update an etherpad?


Can you please share the links?

thanks,
SriD



--
View this message in context: 
http://openstack.10931.n7.nabble.com/Neutron-LBaas-Single-call-API-discussion-tp38533p38542.html
Sent from the Developer mailing list archive at Nabble.com.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807



--
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

Re: [openstack-dev] [Neutron][LBaas] "Single call" API discussion

[Stephen Balukoff]

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?


On Thu, Apr 17, 2014 at 11:44 AM, Stephen Balukoff wrote:

> Hi Sri,
>
> Yes, the meeting minutes & etc. are all available here, usually a few
> minutes after the meeting is over:
> http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/
>
> (You are also, of course, welcome to join!)
>
> Stephen
>
>
> On Thu, Apr 17, 2014 at 11:34 AM, Sri  wrote:
>
>> hello Stephen,
>>
>>
>> I am interested in LBaaS and want to know if we post the weekly meeting's
>> chat transcripts online?
>> or may be update an etherpad?
>>
>>
>> Can you please share the links?
>>
>> thanks,
>> SriD
>>
>>
>>
>> --
>> View this message in context:
>> http://openstack.10931.n7.nabble.com/Neutron-LBaas-Single-call-API-discussion-tp38533p38542.html
>> Sent from the Developer mailing list archive at Nabble.com.
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Stephen Balukoff
> Blue Box Group, LLC
> (800)613-4305 x807
>



-- 
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

Re: [openstack-dev] [Neutron][LBaas] "Single call" API discussion

[Stephen Balukoff]

Hi Sri,

Yes, the meeting minutes & etc. are all available here, usually a few
minutes after the meeting is over:
http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/

(You are also, of course, welcome to join!)

Stephen


On Thu, Apr 17, 2014 at 11:34 AM, Sri  wrote:

> hello Stephen,
>
>
> I am interested in LBaaS and want to know if we post the weekly meeting's
> chat transcripts online?
> or may be update an etherpad?
>
>
> Can you please share the links?
>
> thanks,
> SriD
>
>
>
> --
> View this message in context:
> http://openstack.10931.n7.nabble.com/Neutron-LBaas-Single-call-API-discussion-tp38533p38542.html
> Sent from the Developer mailing list archive at Nabble.com.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
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

Re: [openstack-dev] [Neutron][LBaas] "Single call" API discussion

[Sri]

hello Stephen,


I am interested in LBaaS and want to know if we post the weekly meeting's
chat transcripts online?
or may be update an etherpad?


Can you please share the links?

thanks,
SriD



--
View this message in context: 
http://openstack.10931.n7.nabble.com/Neutron-LBaas-Single-call-API-discussion-tp38533p38543.html
Sent from the Developer mailing list archive at Nabble.com.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaas] "Single call" API discussion

[Sri]

hello Stephen,


I am interested in LBaaS and want to know if we post the weekly meeting's
chat transcripts online?
or may be update an etherpad?


Can you please share the links?

thanks,
SriD



--
View this message in context: 
http://openstack.10931.n7.nabble.com/Neutron-LBaas-Single-call-API-discussion-tp38533p38542.html
Sent from the Developer mailing list archive at Nabble.com.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaas] "Single call" API discussion

[Stephen Balukoff]

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.

* 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'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?

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.

3. Could you describe the most complicated use case that your single-call
API supports? Again, please be very specific here.

4. What percentage of your customer base are used to using single-call
functionality, and what percentage are used to manipulating primitives?

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