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