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.


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"


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 
Having provider defined in multiple places does not make sense.


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


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 

Let's say a monitor was configured with timeout > delay there would be no error 
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?

Vijay V.
OpenStack-dev mailing list

Reply via email to