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 <brandon.lo...@rackspace.com
> 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
> > <vijay.venkatacha...@citrix.com> 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:do...@a10networks.com]
> >
> >         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" <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
> >         _______________________________________________
> >         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
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to