Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver interface on every API request

2014-08-12 Thread Avishay Balderman
Hi
The right layer for this validation is the Neutron REST layer.
Since the current validation engine in this layer can only do attribute level 
validation (e.g make sure timeout is int  and timeout  5) but can't do entity 
level validation (e.g  timeout  delay), you can find entity level validation 
code  in the lbaas plugin layer and in DB layer.

As far as I understand the REST engine of Neutron is about to be replaced (I 
hope before the Z version :) ) and I hope the new engine will be able to run 
entity level validations.

Avishay

From: Samuel Bercovici
Sent: Monday, August 11, 2014 4:58 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver 
interface on every API request

Hi,

Validations such as timeout  delay should be performed on the API level 
before it reaches the driver.

For a configuration tree (lb, listeners, pools, etc.), there should be one 
provider.
Having provider defined in multiple places does not make sense.


-San.


From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
Sent: Monday, August 11, 2014 2:43 PM
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver 
interface on every API request

Hi:

Continuing from last week's LBaaS meeting...

Currently an entity cannot be sent to driver unless it is linked to 
loadbalancer because loadbalancer is the root object and driver information is 
only available with loadbalancer.

The request to the driver is delayed because of which error propagation becomes 
tricky.

Let's say a monitor was configured with timeout  delay there would be no error 
then.
When a listener is configured there will be a monitor creation/deployment error 
like timeout configured greater than delay.

Unless the error is very clearly crafted the user won't be able to understand 
the error.

I am half-heartedly OK with current approach.

But, I would prefer Brandon's Solution - make provider an attribute in each of 
the entities to get rid of this problem.

What do others think?

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


Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver interface on every API request

2014-08-12 Thread Eichberger, German
Hi,

I think we are debating some edge-case. An important part of the flavor 
framework is the ability of me the operator to say failover from Octavia to an 
F5. So as an operator I would ensure to only offer the features in that flavor 
which both support. So in order to arrive at Brandon’s example I would have 
misconfigured my environment and rightfully would get errors at the drive level 
– which might be hard to understand for end users but hopefully pretty clear 
for me the operator…

German

From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Monday, August 11, 2014 9:56 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver 
interface on every API request

Well, that exactly what we've tried to solve with tags in the flavor.

Considering your example with whole configuration being sent to the driver - i 
think it will be fine to not apply unsupported parts of configuration (like 
such HM) and mark the HM object with error status/status description.

Thanks,
Eugene.

On Tue, Aug 12, 2014 at 12:33 AM, Brandon Logan 
brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote:
Hi Eugene,
An example of the HM issue (and really this can happen with any entity)
is if the driver the API sends the configuration to does not actually
support the value of an attribute.

For example: Provider A support PING health monitor type, Provider B
does not.  API allows the PING health monitor type to go through.  Once
a load balancer has been linked with that health monitor and the
LoadBalancer chose to use Provider B, that entire configuration is then
sent to the driver.  The driver errors out not on the LoadBalancer
create, but on the health monitor create.

I think that's the issue.

Thanks,
Brandon

On Tue, 2014-08-12 at 00:17 +0400, Eugene Nikanorov wrote:
 Hi folks,


 That actually going in opposite direction to what flavor framework is
 trying to do (and for dispatching it's doing the same as providers).
 REST call dispatching should really go via the root object.


 I don't quite get the issue with health monitors. If HM is incorrectly
 configured prior to association with a pool - API layer should handle
 that.
 I don't think driver implementations should be different at
 constraints to HM parameters.


 So I'm -1 on adding provider (or flavor) to each entity. After all, it
 looks just like data denormalization which actually will affect lots
 of API aspects in negative way.


 Thanks,
 Eugene.




 On Mon, Aug 11, 2014 at 11:20 PM, Vijay Venkatachalam
 vijay.venkatacha...@citrix.commailto:vijay.venkatacha...@citrix.com wrote:

 Yes, the point was to say the plugin need not restrict and
 let driver decide what to do with the API.

 Even if the call was made to driver instantaneously, I
 understand, the driver might decide to ignore
 first and schedule later. But, if the call is present, there
 is scope for validation.
 Also, the driver might be scheduling an async-api to backend,
 in which case  deployment error
 cannot be shown to the user instantaneously.

 W.r.t. identifying a provider/driver, how would it be to make
 tenant the default root object?
 tenantid is already associated with each of these entities,
 so no additional pain.
 For the tenant who wants to override let him specify provider
 in each of the entities.
 If you think of this in terms of the UI, let's say if the
 loadbalancer configuration is exposed
 as a single wizard (which has loadbalancer, listener, pool,
 monitor properties) then provider
  is chosen only once.

 Curious question, is flavour framework expected to address
 this problem?

 Thanks,
 Vijay V.

 -Original Message-
 From: Doug Wiegley 
 [mailto:do...@a10networks.commailto:do...@a10networks.com]

 Sent: 11 August 2014 22:02
 To: OpenStack Development Mailing List (not for usage
 questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] Continuing on
 Calling driver interface on every API request

 Hi Sam,

 Very true.  I think that Vijay’s objection is that we are
 currently imposing a logical structure on the driver, when it
 should be a driver decision.  Certainly, it goes both ways.

 And I also agree that the mechanism for returning multiple
 errors, and the ability to specify whether those errors are
 fatal or not, individually, is currently weak.

 Doug


 On 8/11/14, 10:21 AM, Samuel Bercovici 
 samu...@radware.commailto:samu...@radware.com
 wrote:

 Hi Doug,
 
 In some implementations Driver !== Device. I think this is
 also true
 for HA Proxy.
 This might mean

Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver interface on every API request

2014-08-11 Thread Samuel Bercovici
Hi,

Validations such as timeout  delay should be performed on the API level 
before it reaches the driver.

For a configuration tree (lb, listeners, pools, etc.), there should be one 
provider.
Having provider defined in multiple places does not make sense.


-San.


From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
Sent: Monday, August 11, 2014 2:43 PM
To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver 
interface on every API request

Hi:

Continuing from last week's LBaaS meeting...

Currently an entity cannot be sent to driver unless it is linked to 
loadbalancer because loadbalancer is the root object and driver information is 
only available with loadbalancer.

The request to the driver is delayed because of which error propagation becomes 
tricky.

Let's say a monitor was configured with timeout  delay there would be no error 
then.
When a listener is configured there will be a monitor creation/deployment error 
like timeout configured greater than delay.

Unless the error is very clearly crafted the user won't be able to understand 
the error.

I am half-heartedly OK with current approach.

But, I would prefer Brandon's Solution - make provider an attribute in each of 
the entities to get rid of this problem.

What do others think?

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


Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver interface on every API request

2014-08-11 Thread Brandon Logan
Yeah what I meant was the only solution I could come up with so that the
driver gets passed every call is to have the every entity have a
provider.  I do believe this is a bit cumbersome for a user, and extra
validation would be needed to verify that two entities linked together
cannot have different providers, but that would be pretty easy.  In my
opinion, it'd be a bit weird to have them all have a provider.  However,
there are some pros to it such as:

1) Driver always gets the create, update, and delete calls.
2) If drivers support a varying range of values for certain entity
attributes, that validation can be caught immediately if thats something
people wanted.
3) Will remove the necessity of a DEFERRED status for some drivers
(This also brings up a CON, in that some drivers may use DEFERRED and
some may not, which leads to an inconsistent UX).
4) Status management in some drivers will become a bit easier.

Still I don't think it is something that should be done because having
the user give a provider for every entity is a bit cumbersome.  Though
if enough people want this then a larger discussion about it should
probably happen.

Thanks,
Brandon

On Mon, 2014-08-11 at 13:57 +, Samuel Bercovici wrote:
 Hi,
 
  
 
 Validations such as “timeout  delay” should be performed on the API
 level before it reaches the driver.
 
  
 
 For a configuration tree (lb, listeners, pools, etc.), there should be
 one provider. 
 
 Having provider defined in multiple places does not make sense.
 
  
 
  
 
 -San.
 
  
 
  
 
 From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com] 
 Sent: Monday, August 11, 2014 2:43 PM
 To: OpenStack Development Mailing List
 (openstack-dev@lists.openstack.org)
 Subject: [openstack-dev] [Neutron][LBaaS] Continuing on Calling
 driver interface on every API request
 
 
  
 
 Hi:
 
  
 
 Continuing from last week’s LBaaS meeting…
 
  
 
 Currently an entity cannot be sent to driver unless it is linked to
 loadbalancer because loadbalancer is the root object and driver
 information is only available with loadbalancer. 
 
  
 
 The request to the driver is delayed because of which error
 propagation becomes tricky.
 
  
 
 Let’s say a monitor was configured with timeout  delay there would be
 no error then.
 
 When a listener is configured there will be a monitor
 creation/deployment error like “timeout configured greater than
 delay”.
 
  
 
 Unless the error is very clearly crafted the user won’t be able to
 understand the error.
 
  
 
 I am half-heartedly OK with current approach. 
 
  
 
 But, I would prefer Brandon’s Solution – make provider an attribute in
 each of the entities to get rid of this problem. 
 
  
 
 What do others think?
 
  
 
 Thanks,
 
 Vijay V.
 
 
 ___
 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] Continuing on Calling driver interface on every API request

2014-08-11 Thread Doug Wiegley
Hi all,

 Validations such as ³timeout  delay² should be performed on the API
level before it reaches the driver.
For a configuration tree (lb, listeners, pools, etc.), there should be one
provider.

You¹re right, but I think the point of Vijay¹s example was to highlight
the combo error problem with populating all of the driver objects at once
(in short, the driver interface isn¹t well suited to that model.)  That
his one example can be covered by API validators is irrelevant.  Consider
a backend that does not support APP_COOKIE¹s, or HTTPS_TERMINATED (but has
multiple listeners) instead.  Should the entire load balancer create fail,
or should it offer degraded service?  Do all drivers have to implement a
transaction rollback; wait, the interface makes that very hard.  That¹s
his point.  The driver is no longer just glue code between interfaces;
it¹s now a mini-object error handler.


 Having provider defined in multiple places does not make sense.

Channeling Brandon, who can yell if I get this wrong, the point is not to
have a potentially different provider on each object.  It¹s to allow a
provider to be assigned when the first object in the tree is created, so
that future related objects will always get routed to the same provider.
Not knowing which provider should get all the objects is why we have to
wait until we see a LoadBalancer object.


All of this sort of edge case nonsense is because we (the royal we, the
community), wanted all load balancer objects to be ³root² objects, even
though only one of them is an actual root today, to support many-to-many
relationships among all of them, at some future date, without an interface
change.  If my bias is showing that I¹m not a fan of adding this
complexity for that, I¹m not surprised.

Thanks,
doug


On 8/11/14, 7:57 AM, Samuel Bercovici samu...@radware.com wrote:

Hi,
 
Validations such as ³timeout  delay² should be performed on the API
level before it reaches the driver.
 
For a configuration tree (lb, listeners, pools, etc.), there should be
one provider.

Having provider defined in multiple places does not make sense.
 
 
-San.
 
 
From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]

Sent: Monday, August 11, 2014 2:43 PM
To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver
interface on every API request


 
Hi:
 
Continuing from last week¹s LBaaS meetingŠ
 
Currently an entity cannot be sent to driver unless it is linked to
loadbalancer because loadbalancer is the root object and driver
information is only available with loadbalancer.

 
The request to the driver is delayed because of which error propagation
becomes tricky.
 
Let¹s say a monitor was configured with timeout  delay there would be no
error then.
When a listener is configured there will be a monitor creation/deployment
error like ³timeout configured greater than delay².
 
Unless the error is very clearly crafted the user won¹t be able to
understand the error.
 
I am half-heartedly OK with current approach.

 
But, I would prefer Brandon¹s Solution ­ make provider an attribute in
each of the entities to get rid of this problem.

 
What do others think?
 
Thanks,
Vijay V.



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


Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver interface on every API request

2014-08-11 Thread Samuel Bercovici
Hi Doug,

In some implementations Driver !== Device. I think this is also true for HA 
Proxy.
This might mean that there is a difference between creating a logical object 
and when there is enough information to actually schedule/place this into a 
device.
The ability to express such errors (detecting an error on a logical object 
after it was created but when it actually get scheduled) should be discussed 
and addressed anyway.

-Sam.


-Original Message-
From: Doug Wiegley [mailto:do...@a10networks.com] 
Sent: Monday, August 11, 2014 6:55 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver 
interface on every API request

Hi all,

 Validations such as ³timeout  delay² should be performed on the API 
level before it reaches the driver.
For a configuration tree (lb, listeners, pools, etc.), there should be one 
provider.

You¹re right, but I think the point of Vijay¹s example was to highlight the 
combo error problem with populating all of the driver objects at once (in 
short, the driver interface isn¹t well suited to that model.)  That his one 
example can be covered by API validators is irrelevant.  Consider a backend 
that does not support APP_COOKIE¹s, or HTTPS_TERMINATED (but has multiple 
listeners) instead.  Should the entire load balancer create fail, or should it 
offer degraded service?  Do all drivers have to implement a transaction 
rollback; wait, the interface makes that very hard.  That¹s his point.  The 
driver is no longer just glue code between interfaces; it¹s now a mini-object 
error handler.


 Having provider defined in multiple places does not make sense.

Channeling Brandon, who can yell if I get this wrong, the point is not to have 
a potentially different provider on each object.  It¹s to allow a provider to 
be assigned when the first object in the tree is created, so that future 
related objects will always get routed to the same provider.
Not knowing which provider should get all the objects is why we have to wait 
until we see a LoadBalancer object.


All of this sort of edge case nonsense is because we (the royal we, the 
community), wanted all load balancer objects to be ³root² objects, even though 
only one of them is an actual root today, to support many-to-many relationships 
among all of them, at some future date, without an interface change.  If my 
bias is showing that I¹m not a fan of adding this complexity for that, I¹m not 
surprised.

Thanks,
doug


On 8/11/14, 7:57 AM, Samuel Bercovici samu...@radware.com wrote:

Hi,
 
Validations such as ³timeout  delay² should be performed on the API 
level before it reaches the driver.
 
For a configuration tree (lb, listeners, pools, etc.), there should be 
one provider.

Having provider defined in multiple places does not make sense.
 
 
-San.
 
 
From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]

Sent: Monday, August 11, 2014 2:43 PM
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver 
interface on every API request


 
Hi:
 
Continuing from last week¹s LBaaS meetingŠ
 
Currently an entity cannot be sent to driver unless it is linked to 
loadbalancer because loadbalancer is the root object and driver 
information is only available with loadbalancer.

 
The request to the driver is delayed because of which error propagation 
becomes tricky.
 
Let¹s say a monitor was configured with timeout  delay there would be 
no error then.
When a listener is configured there will be a monitor 
creation/deployment error like ³timeout configured greater than delay².
 
Unless the error is very clearly crafted the user won¹t be able to 
understand the error.
 
I am half-heartedly OK with current approach.

 
But, I would prefer Brandon¹s Solution ­ make provider an attribute in 
each of the entities to get rid of this problem.

 
What do others think?
 
Thanks,
Vijay V.



___
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] Continuing on Calling driver interface on every API request

2014-08-11 Thread Doug Wiegley
Hi Sam,

Very true.  I think that Vijay’s objection is that we are currently
imposing a logical structure on the driver, when it should be a driver
decision.  Certainly, it goes both ways.

And I also agree that the mechanism for returning multiple errors, and the
ability to specify whether those errors are fatal or not, individually, is
currently weak.

Doug


On 8/11/14, 10:21 AM, Samuel Bercovici samu...@radware.com wrote:

Hi Doug,

In some implementations Driver !== Device. I think this is also true for
HA Proxy.
This might mean that there is a difference between creating a logical
object and when there is enough information to actually schedule/place
this into a device.
The ability to express such errors (detecting an error on a logical
object after it was created but when it actually get scheduled) should be
discussed and addressed anyway.

-Sam.


-Original Message-
From: Doug Wiegley [mailto:do...@a10networks.com]
Sent: Monday, August 11, 2014 6:55 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling
driver interface on every API request

Hi all,

 Validations such as ³timeout  delay² should be performed on the API
level before it reaches the driver.
For a configuration tree (lb, listeners, pools, etc.), there should be
one provider.

You¹re right, but I think the point of Vijay¹s example was to highlight
the combo error problem with populating all of the driver objects at once
(in short, the driver interface isn¹t well suited to that model.)  That
his one example can be covered by API validators is irrelevant.  Consider
a backend that does not support APP_COOKIE¹s, or HTTPS_TERMINATED (but
has multiple listeners) instead.  Should the entire load balancer create
fail, or should it offer degraded service?  Do all drivers have to
implement a transaction rollback; wait, the interface makes that very
hard.  That¹s his point.  The driver is no longer just glue code between
interfaces; it¹s now a mini-object error handler.


 Having provider defined in multiple places does not make sense.

Channeling Brandon, who can yell if I get this wrong, the point is not to
have a potentially different provider on each object.  It¹s to allow a
provider to be assigned when the first object in the tree is created, so
that future related objects will always get routed to the same provider.
Not knowing which provider should get all the objects is why we have to
wait until we see a LoadBalancer object.


All of this sort of edge case nonsense is because we (the royal we, the
community), wanted all load balancer objects to be ³root² objects, even
though only one of them is an actual root today, to support many-to-many
relationships among all of them, at some future date, without an
interface change.  If my bias is showing that I¹m not a fan of adding
this complexity for that, I¹m not surprised.

Thanks,
doug


On 8/11/14, 7:57 AM, Samuel Bercovici samu...@radware.com wrote:

Hi,
 
Validations such as ³timeout  delay² should be performed on the API
level before it reaches the driver.
 
For a configuration tree (lb, listeners, pools, etc.), there should be
one provider.

Having provider defined in multiple places does not make sense.
 
 
-San.
 
 
From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]

Sent: Monday, August 11, 2014 2:43 PM
To: OpenStack Development Mailing List
(openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver
interface on every API request


 
Hi:
 
Continuing from last week¹s LBaaS meetingŠ
 
Currently an entity cannot be sent to driver unless it is linked to
loadbalancer because loadbalancer is the root object and driver
information is only available with loadbalancer.

 
The request to the driver is delayed because of which error propagation
becomes tricky.
 
Let¹s say a monitor was configured with timeout  delay there would be
no error then.
When a listener is configured there will be a monitor
creation/deployment error like ³timeout configured greater than delay².
 
Unless the error is very clearly crafted the user won¹t be able to
understand the error.
 
I am half-heartedly OK with current approach.

 
But, I would prefer Brandon¹s Solution ­ make provider an attribute in
each of the entities to get rid of this problem.

 
What do others think?
 
Thanks,
Vijay V.



___
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] Continuing on Calling driver interface on every API request

2014-08-11 Thread Vijay Venkatachalam

Yes, the point was to say the plugin need not restrict and let driver decide 
what to do with the API.

Even if the call was made to driver instantaneously, I understand, the driver 
might decide to ignore 
first and schedule later. But, if the call is present, there is scope for 
validation. 
Also, the driver might be scheduling an async-api to backend, in which case  
deployment error 
cannot be shown to the user instantaneously.

W.r.t. identifying a provider/driver, how would it be to make tenant the 
default root object? 
tenantid is already associated with each of these entities, so no additional 
pain. 
For the tenant who wants to override let him specify provider in each of the 
entities.
If you think of this in terms of the UI, let's say if the loadbalancer 
configuration is exposed 
as a single wizard (which has loadbalancer, listener, pool, monitor properties) 
then provider
 is chosen only once. 

Curious question, is flavour framework expected to address this problem?

Thanks,
Vijay V.

-Original Message-
From: Doug Wiegley [mailto:do...@a10networks.com] 
Sent: 11 August 2014 22:02
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver 
interface on every API request

Hi Sam,

Very true.  I think that Vijay’s objection is that we are currently imposing a 
logical structure on the driver, when it should be a driver decision.  
Certainly, it goes both ways.

And I also agree that the mechanism for returning multiple errors, and the 
ability to specify whether those errors are fatal or not, individually, is 
currently weak.

Doug


On 8/11/14, 10:21 AM, Samuel Bercovici samu...@radware.com wrote:

Hi Doug,

In some implementations Driver !== Device. I think this is also true 
for HA Proxy.
This might mean that there is a difference between creating a logical 
object and when there is enough information to actually schedule/place 
this into a device.
The ability to express such errors (detecting an error on a logical 
object after it was created but when it actually get scheduled) should 
be discussed and addressed anyway.

-Sam.


-Original Message-
From: Doug Wiegley [mailto:do...@a10networks.com]
Sent: Monday, August 11, 2014 6:55 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling 
driver interface on every API request

Hi all,

 Validations such as ³timeout  delay² should be performed on the API 
level before it reaches the driver.
For a configuration tree (lb, listeners, pools, etc.), there should be 
one provider.

You¹re right, but I think the point of Vijay¹s example was to highlight 
the combo error problem with populating all of the driver objects at 
once (in short, the driver interface isn¹t well suited to that model.)  
That his one example can be covered by API validators is irrelevant.  
Consider a backend that does not support APP_COOKIE¹s, or 
HTTPS_TERMINATED (but has multiple listeners) instead.  Should the 
entire load balancer create fail, or should it offer degraded service?  
Do all drivers have to implement a transaction rollback; wait, the 
interface makes that very hard.  That¹s his point.  The driver is no 
longer just glue code between interfaces; it¹s now a mini-object error handler.


 Having provider defined in multiple places does not make sense.

Channeling Brandon, who can yell if I get this wrong, the point is not 
to have a potentially different provider on each object.  It¹s to allow 
a provider to be assigned when the first object in the tree is created, 
so that future related objects will always get routed to the same provider.
Not knowing which provider should get all the objects is why we have to 
wait until we see a LoadBalancer object.


All of this sort of edge case nonsense is because we (the royal we, the 
community), wanted all load balancer objects to be ³root² objects, even 
though only one of them is an actual root today, to support 
many-to-many relationships among all of them, at some future date, 
without an interface change.  If my bias is showing that I¹m not a fan 
of adding this complexity for that, I¹m not surprised.

Thanks,
doug


On 8/11/14, 7:57 AM, Samuel Bercovici samu...@radware.com wrote:

Hi,
 
Validations such as ³timeout  delay² should be performed on the API 
level before it reaches the driver.
 
For a configuration tree (lb, listeners, pools, etc.), there should be 
one provider.

Having provider defined in multiple places does not make sense.
 
 
-San.
 
 
From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]

Sent: Monday, August 11, 2014 2:43 PM
To: OpenStack Development Mailing List
(openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Neutron][LBaaS] Continuing on Calling 
driver interface on every API request


 
Hi:
 
Continuing from last week¹s LBaaS meetingŠ
 
Currently an entity cannot be sent to driver unless

Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver interface on every API request

2014-08-11 Thread Eugene Nikanorov
Hi folks,

That actually going in opposite direction to what flavor framework is
trying to do (and for dispatching it's doing the same as providers). REST
call dispatching should really go via the root object.

I don't quite get the issue with health monitors. If HM is incorrectly
configured prior to association with a pool - API layer should handle that.
I don't think driver implementations should be different at constraints to
HM parameters.

So I'm -1 on adding provider (or flavor) to each entity. After all, it
looks just like data denormalization which actually will affect lots of API
aspects in negative way.

Thanks,
Eugene.



On Mon, Aug 11, 2014 at 11:20 PM, Vijay Venkatachalam 
vijay.venkatacha...@citrix.com wrote:


 Yes, the point was to say the plugin need not restrict and let driver
 decide what to do with the API.

 Even if the call was made to driver instantaneously, I understand, the
 driver might decide to ignore
 first and schedule later. But, if the call is present, there is scope for
 validation.
 Also, the driver might be scheduling an async-api to backend, in which
 case  deployment error
 cannot be shown to the user instantaneously.

 W.r.t. identifying a provider/driver, how would it be to make tenant the
 default root object?
 tenantid is already associated with each of these entities, so no
 additional pain.
 For the tenant who wants to override let him specify provider in each of
 the entities.
 If you think of this in terms of the UI, let's say if the loadbalancer
 configuration is exposed
 as a single wizard (which has loadbalancer, listener, pool, monitor
 properties) then provider
  is chosen only once.

 Curious question, is flavour framework expected to address this problem?

 Thanks,
 Vijay V.

 -Original Message-
 From: Doug Wiegley [mailto:do...@a10networks.com]
 Sent: 11 August 2014 22:02
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling
 driver interface on every API request

 Hi Sam,

 Very true.  I think that Vijay’s objection is that we are currently
 imposing a logical structure on the driver, when it should be a driver
 decision.  Certainly, it goes both ways.

 And I also agree that the mechanism for returning multiple errors, and the
 ability to specify whether those errors are fatal or not, individually, is
 currently weak.

 Doug


 On 8/11/14, 10:21 AM, Samuel Bercovici samu...@radware.com wrote:

 Hi Doug,
 
 In some implementations Driver !== Device. I think this is also true
 for HA Proxy.
 This might mean that there is a difference between creating a logical
 object and when there is enough information to actually schedule/place
 this into a device.
 The ability to express such errors (detecting an error on a logical
 object after it was created but when it actually get scheduled) should
 be discussed and addressed anyway.
 
 -Sam.
 
 
 -Original Message-
 From: Doug Wiegley [mailto:do...@a10networks.com]
 Sent: Monday, August 11, 2014 6:55 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling
 driver interface on every API request
 
 Hi all,
 
  Validations such as ³timeout  delay² should be performed on the API
 level before it reaches the driver.
 For a configuration tree (lb, listeners, pools, etc.), there should be
 one provider.
 
 You¹re right, but I think the point of Vijay¹s example was to highlight
 the combo error problem with populating all of the driver objects at
 once (in short, the driver interface isn¹t well suited to that model.)
 That his one example can be covered by API validators is irrelevant.
 Consider a backend that does not support APP_COOKIE¹s, or
 HTTPS_TERMINATED (but has multiple listeners) instead.  Should the
 entire load balancer create fail, or should it offer degraded service?
 Do all drivers have to implement a transaction rollback; wait, the
 interface makes that very hard.  That¹s his point.  The driver is no
 longer just glue code between interfaces; it¹s now a mini-object error
 handler.
 
 
  Having provider defined in multiple places does not make sense.
 
 Channeling Brandon, who can yell if I get this wrong, the point is not
 to have a potentially different provider on each object.  It¹s to allow
 a provider to be assigned when the first object in the tree is created,
 so that future related objects will always get routed to the same
 provider.
 Not knowing which provider should get all the objects is why we have to
 wait until we see a LoadBalancer object.
 
 
 All of this sort of edge case nonsense is because we (the royal we, the
 community), wanted all load balancer objects to be ³root² objects, even
 though only one of them is an actual root today, to support
 many-to-many relationships among all of them, at some future date,
 without an interface change.  If my bias is showing that I¹m not a fan
 of adding this complexity

Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver interface on every API request

2014-08-11 Thread Brandon Logan
Hi Eugene,
An example of the HM issue (and really this can happen with any entity)
is if the driver the API sends the configuration to does not actually
support the value of an attribute.

For example: Provider A support PING health monitor type, Provider B
does not.  API allows the PING health monitor type to go through.  Once
a load balancer has been linked with that health monitor and the
LoadBalancer chose to use Provider B, that entire configuration is then
sent to the driver.  The driver errors out not on the LoadBalancer
create, but on the health monitor create.

I think that's the issue.

Thanks,
Brandon

On Tue, 2014-08-12 at 00:17 +0400, Eugene Nikanorov wrote:
 Hi folks,
 
 
 That actually going in opposite direction to what flavor framework is
 trying to do (and for dispatching it's doing the same as providers).
 REST call dispatching should really go via the root object.
 
 
 I don't quite get the issue with health monitors. If HM is incorrectly
 configured prior to association with a pool - API layer should handle
 that.
 I don't think driver implementations should be different at
 constraints to HM parameters.
 
 
 So I'm -1 on adding provider (or flavor) to each entity. After all, it
 looks just like data denormalization which actually will affect lots
 of API aspects in negative way.
 
 
 Thanks,
 Eugene.
 
 
 
 
 On Mon, Aug 11, 2014 at 11:20 PM, Vijay Venkatachalam
 vijay.venkatacha...@citrix.com wrote:
 
 Yes, the point was to say the plugin need not restrict and
 let driver decide what to do with the API.
 
 Even if the call was made to driver instantaneously, I
 understand, the driver might decide to ignore
 first and schedule later. But, if the call is present, there
 is scope for validation.
 Also, the driver might be scheduling an async-api to backend,
 in which case  deployment error
 cannot be shown to the user instantaneously.
 
 W.r.t. identifying a provider/driver, how would it be to make
 tenant the default root object?
 tenantid is already associated with each of these entities,
 so no additional pain.
 For the tenant who wants to override let him specify provider
 in each of the entities.
 If you think of this in terms of the UI, let's say if the
 loadbalancer configuration is exposed
 as a single wizard (which has loadbalancer, listener, pool,
 monitor properties) then provider
  is chosen only once.
 
 Curious question, is flavour framework expected to address
 this problem?
 
 Thanks,
 Vijay V.
 
 -Original Message-
 From: Doug Wiegley [mailto:do...@a10networks.com]
 
 Sent: 11 August 2014 22:02
 To: OpenStack Development Mailing List (not for usage
 questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] Continuing on
 Calling driver interface on every API request
 
 Hi Sam,
 
 Very true.  I think that Vijay’s objection is that we are
 currently imposing a logical structure on the driver, when it
 should be a driver decision.  Certainly, it goes both ways.
 
 And I also agree that the mechanism for returning multiple
 errors, and the ability to specify whether those errors are
 fatal or not, individually, is currently weak.
 
 Doug
 
 
 On 8/11/14, 10:21 AM, Samuel Bercovici samu...@radware.com
 wrote:
 
 Hi Doug,
 
 In some implementations Driver !== Device. I think this is
 also true
 for HA Proxy.
 This might mean that there is a difference between creating a
 logical
 object and when there is enough information to actually
 schedule/place
 this into a device.
 The ability to express such errors (detecting an error on a
 logical
 object after it was created but when it actually get
 scheduled) should
 be discussed and addressed anyway.
 
 -Sam.
 
 
 -Original Message-
 From: Doug Wiegley [mailto:do...@a10networks.com]
 Sent: Monday, August 11, 2014 6:55 PM
 To: OpenStack Development Mailing List (not for usage
 questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] Continuing on
 Calling
 driver interface on every API request
 
 Hi all,
 
  Validations such as ³timeout  delay² should be performed
 on the API
 level before it reaches the driver.
 For a configuration tree (lb, listeners, pools, etc.), there
 should be
 one provider.
 
 You¹re right, but I think the point of Vijay¹s example was to
 highlight

Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver interface on every API request

2014-08-11 Thread Eugene Nikanorov
Well, that exactly what we've tried to solve with tags in the flavor.

Considering your example with whole configuration being sent to the driver
- i think it will be fine to not apply unsupported parts of configuration
(like such HM) and mark the HM object with error status/status description.

Thanks,
Eugene.


On Tue, Aug 12, 2014 at 12:33 AM, Brandon Logan brandon.lo...@rackspace.com
 wrote:

 Hi Eugene,
 An example of the HM issue (and really this can happen with any entity)
 is if the driver the API sends the configuration to does not actually
 support the value of an attribute.

 For example: Provider A support PING health monitor type, Provider B
 does not.  API allows the PING health monitor type to go through.  Once
 a load balancer has been linked with that health monitor and the
 LoadBalancer chose to use Provider B, that entire configuration is then
 sent to the driver.  The driver errors out not on the LoadBalancer
 create, but on the health monitor create.

 I think that's the issue.

 Thanks,
 Brandon

 On Tue, 2014-08-12 at 00:17 +0400, Eugene Nikanorov wrote:
  Hi folks,
 
 
  That actually going in opposite direction to what flavor framework is
  trying to do (and for dispatching it's doing the same as providers).
  REST call dispatching should really go via the root object.
 
 
  I don't quite get the issue with health monitors. If HM is incorrectly
  configured prior to association with a pool - API layer should handle
  that.
  I don't think driver implementations should be different at
  constraints to HM parameters.
 
 
  So I'm -1 on adding provider (or flavor) to each entity. After all, it
  looks just like data denormalization which actually will affect lots
  of API aspects in negative way.
 
 
  Thanks,
  Eugene.
 
 
 
 
  On Mon, Aug 11, 2014 at 11:20 PM, Vijay Venkatachalam
  vijay.venkatacha...@citrix.com wrote:
 
  Yes, the point was to say the plugin need not restrict and
  let driver decide what to do with the API.
 
  Even if the call was made to driver instantaneously, I
  understand, the driver might decide to ignore
  first and schedule later. But, if the call is present, there
  is scope for validation.
  Also, the driver might be scheduling an async-api to backend,
  in which case  deployment error
  cannot be shown to the user instantaneously.
 
  W.r.t. identifying a provider/driver, how would it be to make
  tenant the default root object?
  tenantid is already associated with each of these entities,
  so no additional pain.
  For the tenant who wants to override let him specify provider
  in each of the entities.
  If you think of this in terms of the UI, let's say if the
  loadbalancer configuration is exposed
  as a single wizard (which has loadbalancer, listener, pool,
  monitor properties) then provider
   is chosen only once.
 
  Curious question, is flavour framework expected to address
  this problem?
 
  Thanks,
  Vijay V.
 
  -Original Message-
  From: Doug Wiegley [mailto:do...@a10networks.com]
 
  Sent: 11 August 2014 22:02
  To: OpenStack Development Mailing List (not for usage
  questions)
  Subject: Re: [openstack-dev] [Neutron][LBaaS] Continuing on
  Calling driver interface on every API request
 
  Hi Sam,
 
  Very true.  I think that Vijay’s objection is that we are
  currently imposing a logical structure on the driver, when it
  should be a driver decision.  Certainly, it goes both ways.
 
  And I also agree that the mechanism for returning multiple
  errors, and the ability to specify whether those errors are
  fatal or not, individually, is currently weak.
 
  Doug
 
 
  On 8/11/14, 10:21 AM, Samuel Bercovici samu...@radware.com
  wrote:
 
  Hi Doug,
  
  In some implementations Driver !== Device. I think this is
  also true
  for HA Proxy.
  This might mean that there is a difference between creating a
  logical
  object and when there is enough information to actually
  schedule/place
  this into a device.
  The ability to express such errors (detecting an error on a
  logical
  object after it was created but when it actually get
  scheduled) should
  be discussed and addressed anyway.
  
  -Sam.
  
  
  -Original Message-
  From: Doug Wiegley [mailto:do...@a10networks.com]
  Sent: Monday, August 11, 2014 6:55 PM
  To: OpenStack Development Mailing List (not for usage
  questions)
  Subject: Re: [openstack-dev] [Neutron][LBaaS] Continuing on
  Calling
  driver interface on every API