[openstack-dev] [Neutron][LBaaS] Continuing on "Calling driver interface on every API request"
Eugene Nikanorov
enikanorov at mirantis.com
Tue Aug 12 04:55:55 UTC 2014
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.logan at 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.Venkatachalam at 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:dougw at 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" <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
> >
> > _______________________________________________
> > 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
> >
> >
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140812/b8225da6/attachment.html>
More information about the OpenStack-dev
mailing list