Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver interface on every API request
Hi The right layer for this validation is the Neutron REST layer. Since the current validation engine in this layer can only do attribute level validation (e.g make sure timeout is int and timeout 5) but can't do entity level validation (e.g timeout delay), you can find entity level validation code in the lbaas plugin layer and in DB layer. As far as I understand the REST engine of Neutron is about to be replaced (I hope before the Z version :) ) and I hope the new engine will be able to run entity level validations. Avishay From: Samuel Bercovici Sent: Monday, August 11, 2014 4:58 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, 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.orgmailto: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
Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver interface on every API request
Hi, I think we are debating some edge-case. An important part of the flavor framework is the ability of me the operator to say failover from Octavia to an F5. So as an operator I would ensure to only offer the features in that flavor which both support. So in order to arrive at Brandon’s example I would have misconfigured my environment and rightfully would get errors at the drive level – which might be hard to understand for end users but hopefully pretty clear for me the operator… German From: Eugene Nikanorov [mailto:enikano...@mirantis.com] Sent: Monday, August 11, 2014 9:56 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 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.commailto: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.commailto: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.commailto: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.commailto:samu...@radware.com wrote: Hi Doug, In some implementations Driver !== Device. I think this is also true for HA Proxy. This might mean
[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
Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver interface on every API request
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
Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver interface on every API request
Yeah what I meant was the only solution I could come up with so that the driver gets passed every call is to have the every entity have a provider. I do believe this is a bit cumbersome for a user, and extra validation would be needed to verify that two entities linked together cannot have different providers, but that would be pretty easy. In my opinion, it'd be a bit weird to have them all have a provider. However, there are some pros to it such as: 1) Driver always gets the create, update, and delete calls. 2) If drivers support a varying range of values for certain entity attributes, that validation can be caught immediately if thats something people wanted. 3) Will remove the necessity of a DEFERRED status for some drivers (This also brings up a CON, in that some drivers may use DEFERRED and some may not, which leads to an inconsistent UX). 4) Status management in some drivers will become a bit easier. Still I don't think it is something that should be done because having the user give a provider for every entity is a bit cumbersome. Though if enough people want this then a larger discussion about it should probably happen. Thanks, Brandon On Mon, 2014-08-11 at 13:57 +, Samuel Bercovici 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
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
Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver interface on every API request
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
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
Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver interface on every API request
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
Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver interface on every API request
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
Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver interface on every API request
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
Re: [openstack-dev] [Neutron][LBaaS] Continuing on Calling driver interface on every API request
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
