Open Stack

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