Well, that exactly what we've tried to solve with tags in the flavor. 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.
Thanks, Eugene. On Tue, Aug 12, 2014 at 12:33 AM, Brandon Logan <[email protected] > wrote: > Hi Eugene, > An example of the HM issue (and really this can happen with any entity) > is if the driver the API sends the configuration to does not actually > support the value of an attribute. > > For example: Provider A support PING health monitor type, Provider B > does not. API allows the PING health monitor type to go through. Once > a load balancer has been linked with that health monitor and the > LoadBalancer chose to use Provider B, that entire configuration is then > sent to the driver. The driver errors out not on the LoadBalancer > create, but on the health monitor create. > > I think that's the issue. > > Thanks, > Brandon > > On Tue, 2014-08-12 at 00:17 +0400, Eugene Nikanorov wrote: > > Hi folks, > > > > > > That actually going in opposite direction to what flavor framework is > > trying to do (and for dispatching it's doing the same as providers). > > REST call dispatching should really go via the root object. > > > > > > I don't quite get the issue with health monitors. If HM is incorrectly > > configured prior to association with a pool - API layer should handle > > that. > > I don't think driver implementations should be different at > > constraints to HM parameters. > > > > > > So I'm -1 on adding provider (or flavor) to each entity. After all, it > > looks just like data denormalization which actually will affect lots > > of API aspects in negative way. > > > > > > Thanks, > > Eugene. > > > > > > > > > > On Mon, Aug 11, 2014 at 11:20 PM, Vijay Venkatachalam > > <[email protected]> wrote: > > > > Yes, the point was to say "the plugin need not restrict and > > let driver decide what to do with the API". > > > > Even if the call was made to driver instantaneously, I > > understand, the driver might decide to ignore > > first and schedule later. But, if the call is present, there > > is scope for validation. > > Also, the driver might be scheduling an async-api to backend, > > in which case deployment error > > cannot be shown to the user instantaneously. > > > > W.r.t. identifying a provider/driver, how would it be to make > > tenant the default "root" object? > > "tenantid" is already associated with each of these entities, > > so no additional pain. > > For the tenant who wants to override let him specify provider > > in each of the entities. > > If you think of this in terms of the UI, let's say if the > > loadbalancer configuration is exposed > > as a single wizard (which has loadbalancer, listener, pool, > > monitor properties) then provider > > is chosen only once. > > > > Curious question, is flavour framework expected to address > > this problem? > > > > Thanks, > > Vijay V. > > > > -----Original Message----- > > From: Doug Wiegley [mailto:[email protected]] > > > > Sent: 11 August 2014 22:02 > > 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 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" <[email protected]> > > 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:[email protected]] > > >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" <[email protected]> > > 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:[email protected]] > > >> > > >>Sent: Monday, August 11, 2014 2:43 PM > > >>To: OpenStack Development Mailing List > > >>([email protected]) > > >>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 > > >[email protected] > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > >_______________________________________________ > > >OpenStack-dev mailing list > > >[email protected] > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
