Open Stack

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.Venkatachalam at citrix.com]
Sent: Monday, August 11, 2014 2:43 PM
To: OpenStack Development Mailing List (openstack-dev at lists.openstack.org<mailto:openstack-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140812/afd57b7c/attachment.html>