Open Stack

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" <SamuelB at 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:dougw at 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" <SamuelB at 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.Venkatachalam at citrix.com]
>>
>>Sent: Monday, August 11, 2014 2:43 PM
>>To: OpenStack Development Mailing List
>>(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.
>>
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev