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

Reply via email to