<div dir="ltr">Well, that exactly what we've tried to solve with tags in the flavor.<div><br></div><div>Considering your example with whole configuration being sent to the driver - i think it will be fine to not apply unsupported parts of configuration (like such HM) and mark the HM object with error status/status description.</div>
<div><br></div><div>Thanks,</div><div>Eugene.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 12, 2014 at 12:33 AM, Brandon Logan <span dir="ltr"><<a href="mailto:brandon.logan@rackspace.com" target="_blank">brandon.logan@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Eugene,<br>
An example of the HM issue (and really this can happen with any entity)<br>
is if the driver the API sends the configuration to does not actually<br>
support the value of an attribute.<br>
<br>
For example: Provider A support PING health monitor type, Provider B<br>
does not. API allows the PING health monitor type to go through. Once<br>
a load balancer has been linked with that health monitor and the<br>
LoadBalancer chose to use Provider B, that entire configuration is then<br>
sent to the driver. The driver errors out not on the LoadBalancer<br>
create, but on the health monitor create.<br>
<br>
I think that's the issue.<br>
<br>
Thanks,<br>
Brandon<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, 2014-08-12 at 00:17 +0400, Eugene Nikanorov wrote:<br>
> Hi folks,<br>
><br>
><br>
> That actually going in opposite direction to what flavor framework is<br>
> trying to do (and for dispatching it's doing the same as providers).<br>
> REST call dispatching should really go via the root object.<br>
><br>
><br>
> I don't quite get the issue with health monitors. If HM is incorrectly<br>
> configured prior to association with a pool - API layer should handle<br>
> that.<br>
> I don't think driver implementations should be different at<br>
> constraints to HM parameters.<br>
><br>
><br>
> So I'm -1 on adding provider (or flavor) to each entity. After all, it<br>
> looks just like data denormalization which actually will affect lots<br>
> of API aspects in negative way.<br>
><br>
><br>
> Thanks,<br>
> Eugene.<br>
><br>
><br>
><br>
><br>
> On Mon, Aug 11, 2014 at 11:20 PM, Vijay Venkatachalam<br>
> <<a href="mailto:Vijay.Venkatachalam@citrix.com">Vijay.Venkatachalam@citrix.com</a>> wrote:<br>
><br>
> Yes, the point was to say "the plugin need not restrict and<br>
> let driver decide what to do with the API".<br>
><br>
> Even if the call was made to driver instantaneously, I<br>
> understand, the driver might decide to ignore<br>
> first and schedule later. But, if the call is present, there<br>
> is scope for validation.<br>
> Also, the driver might be scheduling an async-api to backend,<br>
> in which case deployment error<br>
> cannot be shown to the user instantaneously.<br>
><br>
> W.r.t. identifying a provider/driver, how would it be to make<br>
> tenant the default "root" object?<br>
> "tenantid" is already associated with each of these entities,<br>
> so no additional pain.<br>
> For the tenant who wants to override let him specify provider<br>
> in each of the entities.<br>
> If you think of this in terms of the UI, let's say if the<br>
> loadbalancer configuration is exposed<br>
> as a single wizard (which has loadbalancer, listener, pool,<br>
> monitor properties) then provider<br>
> is chosen only once.<br>
><br>
> Curious question, is flavour framework expected to address<br>
> this problem?<br>
><br>
> Thanks,<br>
> Vijay V.<br>
><br>
> -----Original Message-----<br>
> From: Doug Wiegley [mailto:<a href="mailto:dougw@a10networks.com">dougw@a10networks.com</a>]<br>
><br>
> Sent: 11 August 2014 22:02<br>
> To: OpenStack Development Mailing List (not for usage<br>
> questions)<br>
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Continuing on<br>
> "Calling driver interface on every API request"<br>
><br>
> Hi Sam,<br>
><br>
> Very true. I think that Vijay’s objection is that we are<br>
> currently imposing a logical structure on the driver, when it<br>
> should be a driver decision. Certainly, it goes both ways.<br>
><br>
> And I also agree that the mechanism for returning multiple<br>
> errors, and the ability to specify whether those errors are<br>
> fatal or not, individually, is currently weak.<br>
><br>
> Doug<br>
><br>
><br>
> On 8/11/14, 10:21 AM, "Samuel Bercovici" <SamuelB@Radware.com><br>
> wrote:<br>
><br>
> >Hi Doug,<br>
> ><br>
> >In some implementations Driver !== Device. I think this is<br>
> also true<br>
> >for HA Proxy.<br>
> >This might mean that there is a difference between creating a<br>
> logical<br>
> >object and when there is enough information to actually<br>
> schedule/place<br>
> >this into a device.<br>
> >The ability to express such errors (detecting an error on a<br>
> logical<br>
> >object after it was created but when it actually get<br>
> scheduled) should<br>
> >be discussed and addressed anyway.<br>
> ><br>
> >-Sam.<br>
> ><br>
> ><br>
> >-----Original Message-----<br>
> >From: Doug Wiegley [mailto:<a href="mailto:dougw@a10networks.com">dougw@a10networks.com</a>]<br>
> >Sent: Monday, August 11, 2014 6:55 PM<br>
> >To: OpenStack Development Mailing List (not for usage<br>
> questions)<br>
> >Subject: Re: [openstack-dev] [Neutron][LBaaS] Continuing on<br>
> "Calling<br>
> >driver interface on every API request"<br>
> ><br>
> >Hi all,<br>
> ><br>
> >> Validations such as ³timeout > delay² should be performed<br>
> on the API<br>
> >>level before it reaches the driver.<br>
> >For a configuration tree (lb, listeners, pools, etc.), there<br>
> should be<br>
> >one provider.<br>
> ><br>
> >You¹re right, but I think the point of Vijay¹s example was to<br>
> highlight<br>
> >the combo error problem with populating all of the driver<br>
> objects at<br>
> >once (in short, the driver interface isn¹t well suited to<br>
> that model.)<br>
> >That his one example can be covered by API validators is<br>
> irrelevant.<br>
> >Consider a backend that does not support APP_COOKIE¹s, or<br>
> >HTTPS_TERMINATED (but has multiple listeners) instead.<br>
> Should the<br>
> >entire load balancer create fail, or should it offer degraded<br>
> service?<br>
> >Do all drivers have to implement a transaction rollback;<br>
> wait, the<br>
> >interface makes that very hard. That¹s his point. The<br>
> driver is no<br>
> >longer just glue code between interfaces; it¹s now a<br>
> mini-object error handler.<br>
> ><br>
> ><br>
> >> Having provider defined in multiple places does not make<br>
> sense.<br>
> ><br>
> >Channeling Brandon, who can yell if I get this wrong, the<br>
> point is not<br>
> >to have a potentially different provider on each object.<br>
> It¹s to allow<br>
> >a provider to be assigned when the first object in the tree<br>
> is created,<br>
> >so that future related objects will always get routed to the<br>
> same provider.<br>
> >Not knowing which provider should get all the objects is why<br>
> we have to<br>
> >wait until we see a LoadBalancer object.<br>
> ><br>
> ><br>
> >All of this sort of edge case nonsense is because we (the<br>
> royal we, the<br>
> >community), wanted all load balancer objects to be ³root²<br>
> objects, even<br>
> >though only one of them is an actual root today, to support<br>
> >many-to-many relationships among all of them, at some future<br>
> date,<br>
> >without an interface change. If my bias is showing that I¹m<br>
> not a fan<br>
> >of adding this complexity for that, I¹m not surprised.<br>
> ><br>
> >Thanks,<br>
> >doug<br>
> ><br>
> ><br>
> >On 8/11/14, 7:57 AM, "Samuel Bercovici" <SamuelB@Radware.com><br>
> wrote:<br>
> ><br>
> >>Hi,<br>
> >><br>
> >>Validations such as ³timeout > delay² should be performed on<br>
> the API<br>
> >>level before it reaches the driver.<br>
> >><br>
> >>For a configuration tree (lb, listeners, pools, etc.), there<br>
> should be<br>
> >>one provider.<br>
> >><br>
> >>Having provider defined in multiple places does not make<br>
> sense.<br>
> >><br>
> >><br>
> >>-San.<br>
> >><br>
> >><br>
> >>From: Vijay Venkatachalam<br>
> [mailto:<a href="mailto:Vijay.Venkatachalam@citrix.com">Vijay.Venkatachalam@citrix.com</a>]<br>
> >><br>
> >>Sent: Monday, August 11, 2014 2:43 PM<br>
> >>To: OpenStack Development Mailing List<br>
> >>(<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>)<br>
> >>Subject: [openstack-dev] [Neutron][LBaaS] Continuing on<br>
> "Calling<br>
> >>driver interface on every API request"<br>
> >><br>
> >><br>
> >><br>
> >>Hi:<br>
> >><br>
> >>Continuing from last week¹s LBaaS meetingŠ<br>
> >><br>
> >>Currently an entity cannot be sent to driver unless it is<br>
> linked to<br>
> >>loadbalancer because loadbalancer is the root object and<br>
> driver<br>
> >>information is only available with loadbalancer.<br>
> >><br>
> >><br>
> >>The request to the driver is delayed because of which error<br>
> >>propagation becomes tricky.<br>
> >><br>
> >>Let¹s say a monitor was configured with timeout > delay<br>
> there would be<br>
> >>no error then.<br>
> >>When a listener is configured there will be a monitor<br>
> >>creation/deployment error like ³timeout configured greater<br>
> than delay².<br>
> >><br>
> >>Unless the error is very clearly crafted the user won¹t be<br>
> able to<br>
> >>understand the error.<br>
> >><br>
> >>I am half-heartedly OK with current approach.<br>
> >><br>
> >><br>
> >>But, I would prefer Brandon¹s Solution make provider an<br>
> attribute in<br>
> >>each of the entities to get rid of this problem.<br>
> >><br>
> >><br>
> >>What do others think?<br>
> >><br>
> >>Thanks,<br>
> >>Vijay V.<br>
> >><br>
> ><br>
> ><br>
> >_______________________________________________<br>
> >OpenStack-dev mailing list<br>
> ><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> ><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> >_______________________________________________<br>
> >OpenStack-dev mailing list<br>
> ><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> ><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>