Re: [openstack-dev] [Neutron][LBaaS] Layer7 Switching - L7 Rule - comapre_type values
I also don't think it is fair for certain drivers to hold other drivers hostage For some time there was a policy (openstack-wide) that public API should have a free open source implementation. In this sense open source driver may hold other drivers as hostages. Eugene. On Thu, Jul 3, 2014 at 10:37 PM, Jorge Miramontes jorge.miramon...@rackspace.com wrote: I agree. Also, since we are planning on having two different API versions run in parallel the only driver that needs to be worked on initially is the reference implementation. I'm guessing we will have two reference implementations, one for v1 and one for v2. The v2 implementation currently seems to be modified from v1 in order to get the highest velocity in terms of exposing API functionality. There is a reason we aren't working on Octavia right now and I think the same rationale holds for other drivers. So, I believe we should expose as much functionality possible with a functional open-source driver and then other drivers will catch up. As for drivers that can't implement certain features the only potential issue I see is a type of vendor lock-in. For example, let's say I am an operator agnostic power API user. I host with operator A and they use a driver that implements all functionality exposed via the API. Now, let's say I want to move to operator B because operator A isn't working for me. Let's also say that operator B doesn't implement all functionality exposed via the API. From the user's perspective they are locked out of going to operator B because their API integrated code won't port seamlessly. With this example in mind, however, I also don't think it is fair for certain drivers to hold other drivers hostage. From my perspective, if users really want a feature then every driver implementor should have the incentive to implement said feature and will benefit them in the long run. Anyways, that my $0.02. Cheers, --Jorge From: Stephen Balukoff sbaluk...@bluebox.net Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, June 24, 2014 7:30 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Layer7 Switching - L7 Rule - comapre_type values Making sure all drivers support the features offered in Neutron LBaaS means we are stuck going with the 'least common denominator' in all cases. While this ensures all vendors implement the same things in the functionally the same way, it also is probably a big reason the Neutron LBaaS project has been so incredibly slow in seeing new features added over the last two years. In the gerrit review that Dustin linked, it sounds like the people contributing to the discussion are in favor of allowing drivers to reject some configurations as unsupported through use of exceptions (details on how that will work is being hashed out now if you want to participate in that discussion). Let's assume, therefore, that with the LBaaS v2 API and Object model we're also going to get this ability-- which of course also means that drivers do not have to support every feature exposed by the API. (And again, as Dustin pointed out, a Linux LVS-based driver definitely wouldn't be able to support any L7 features at all, yet it's still a very useful driver for many deployments.) Finally, I do not believe that the LBaaS project should be held back because one vendor's implementation doesn't work well with a couple features exposed in the API. As Dustin said, let the API expose a rich feature set and allow drivers to reject certain configurations when they don't support them. Stephen On Tue, Jun 24, 2014 at 9:09 AM, Dustin Lundquist dus...@null-ptr.net wrote: I brought this up on https://review.openstack.org/#/c/101084/. -Dustin On Tue, Jun 24, 2014 at 7:57 AM, Avishay Balderman avish...@radware.com wrote: Hi Dustin I agree with the concept you described but as far as I understand it is not currently supported in Neutron. So a driver should be fully compatible with the interface it implements. Avishay *From:* Dustin Lundquist [mailto:dus...@null-ptr.net] *Sent:* Tuesday, June 24, 2014 5:41 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Layer7 Switching - L7 Rule - comapre_type values I think the API should provide an richly featured interface, and individual drivers should indicate if they support the provided configuration. For example there is a spec for a Linux LVS LBaaS driver, this driver would not support TLS termination or any layer 7 features, but would still be valuable for some deployments. The user experience of such a solution could be improved if the driver to propagate up a message specifically identifying the unsupported feature. -Dustin On Tue, Jun 24, 2014
Re: [openstack-dev] [Neutron][LBaaS] Layer7 Switching - L7 Rule - comapre_type values
I was implying that it applies to all drivers. Cheers, --Jorge From: Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, July 3, 2014 3:30 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Layer7 Switching - L7 Rule - comapre_type values I also don't think it is fair for certain drivers to hold other drivers hostage For some time there was a policy (openstack-wide) that public API should have a free open source implementation. In this sense open source driver may hold other drivers as hostages. Eugene. On Thu, Jul 3, 2014 at 10:37 PM, Jorge Miramontes jorge.miramon...@rackspace.commailto:jorge.miramon...@rackspace.com wrote: I agree. Also, since we are planning on having two different API versions run in parallel the only driver that needs to be worked on initially is the reference implementation. I'm guessing we will have two reference implementations, one for v1 and one for v2. The v2 implementation currently seems to be modified from v1 in order to get the highest velocity in terms of exposing API functionality. There is a reason we aren't working on Octavia right now and I think the same rationale holds for other drivers. So, I believe we should expose as much functionality possible with a functional open-source driver and then other drivers will catch up. As for drivers that can't implement certain features the only potential issue I see is a type of vendor lock-in. For example, let's say I am an operator agnostic power API user. I host with operator A and they use a driver that implements all functionality exposed via the API. Now, let's say I want to move to operator B because operator A isn't working for me. Let's also say that operator B doesn't implement all functionality exposed via the API. From the user's perspective they are locked out of going to operator B because their API integrated code won't port seamlessly. With this example in mind, however, I also don't think it is fair for certain drivers to hold other drivers hostage. From my perspective, if users really want a feature then every driver implementor should have the incentive to implement said feature and will benefit them in the long run. Anyways, that my $0.02. Cheers, --Jorge From: Stephen Balukoff sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, June 24, 2014 7:30 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Layer7 Switching - L7 Rule - comapre_type values Making sure all drivers support the features offered in Neutron LBaaS means we are stuck going with the 'least common denominator' in all cases. While this ensures all vendors implement the same things in the functionally the same way, it also is probably a big reason the Neutron LBaaS project has been so incredibly slow in seeing new features added over the last two years. In the gerrit review that Dustin linked, it sounds like the people contributing to the discussion are in favor of allowing drivers to reject some configurations as unsupported through use of exceptions (details on how that will work is being hashed out now if you want to participate in that discussion). Let's assume, therefore, that with the LBaaS v2 API and Object model we're also going to get this ability-- which of course also means that drivers do not have to support every feature exposed by the API. (And again, as Dustin pointed out, a Linux LVS-based driver definitely wouldn't be able to support any L7 features at all, yet it's still a very useful driver for many deployments.) Finally, I do not believe that the LBaaS project should be held back because one vendor's implementation doesn't work well with a couple features exposed in the API. As Dustin said, let the API expose a rich feature set and allow drivers to reject certain configurations when they don't support them. Stephen On Tue, Jun 24, 2014 at 9:09 AM, Dustin Lundquist dus...@null-ptr.netmailto:dus...@null-ptr.net wrote: I brought this up on https://review.openstack.org/#/c/101084/. -Dustin On Tue, Jun 24, 2014 at 7:57 AM, Avishay Balderman avish...@radware.commailto:avish...@radware.com wrote: Hi Dustin I agree with the concept you described but as far as I understand it is not currently supported in Neutron. So a driver should be fully compatible with the interface it implements. Avishay From: Dustin Lundquist [mailto:dus...@null-ptr.netmailto:dus...@null
Re: [openstack-dev] [Neutron][LBaaS] Layer7 Switching - L7 Rule - comapre_type values
I think the API should provide an richly featured interface, and individual drivers should indicate if they support the provided configuration. For example there is a spec for a Linux LVS LBaaS driver, this driver would not support TLS termination or any layer 7 features, but would still be valuable for some deployments. The user experience of such a solution could be improved if the driver to propagate up a message specifically identifying the unsupported feature. -Dustin On Tue, Jun 24, 2014 at 4:28 AM, Avishay Balderman avish...@radware.com wrote: Hi One of L7 Rule attributes is ‘compare_type’. This field is the match operator that the rule should activate against the value found in the request. Below is list of the possible values: - Regexp - StartsWith - EndsWith - Contains - EqualTo (*) - GreaterThan (*) - LessThan (*) The last 3 operators (*) in the list are used in numerical matches. Radware load balancing backend does not support those operators “out of the box” and a significant development effort should be done in order to support it. We are afraid to miss the Junu timeframe if we will have to focus in supporting the numerical operators. Therefore we ask to support the non-numerical operators for Junu and add the numerical operators support post Junu. See https://review.openstack.org/#/c/99709/4/specs/juno/lbaas-l7-rules.rst Thanks Avishay ___ 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] Layer7 Switching - L7 Rule - comapre_type values
Hi Dustin I agree with the concept you described but as far as I understand it is not currently supported in Neutron. So a driver should be fully compatible with the interface it implements. Avishay From: Dustin Lundquist [mailto:dus...@null-ptr.net] Sent: Tuesday, June 24, 2014 5:41 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Layer7 Switching - L7 Rule - comapre_type values I think the API should provide an richly featured interface, and individual drivers should indicate if they support the provided configuration. For example there is a spec for a Linux LVS LBaaS driver, this driver would not support TLS termination or any layer 7 features, but would still be valuable for some deployments. The user experience of such a solution could be improved if the driver to propagate up a message specifically identifying the unsupported feature. -Dustin On Tue, Jun 24, 2014 at 4:28 AM, Avishay Balderman avish...@radware.commailto:avish...@radware.com wrote: Hi One of L7 Rule attributes is ‘compare_type’. This field is the match operator that the rule should activate against the value found in the request. Below is list of the possible values: - Regexp - StartsWith - EndsWith - Contains - EqualTo (*) - GreaterThan (*) - LessThan (*) The last 3 operators (*) in the list are used in numerical matches. Radware load balancing backend does not support those operators “out of the box” and a significant development effort should be done in order to support it. We are afraid to miss the Junu timeframe if we will have to focus in supporting the numerical operators. Therefore we ask to support the non-numerical operators for Junu and add the numerical operators support post Junu. See https://review.openstack.org/#/c/99709/4/specs/juno/lbaas-l7-rules.rst Thanks Avishay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] Layer7 Switching - L7 Rule - comapre_type values
I brought this up on https://review.openstack.org/#/c/101084/. -Dustin On Tue, Jun 24, 2014 at 7:57 AM, Avishay Balderman avish...@radware.com wrote: Hi Dustin I agree with the concept you described but as far as I understand it is not currently supported in Neutron. So a driver should be fully compatible with the interface it implements. Avishay *From:* Dustin Lundquist [mailto:dus...@null-ptr.net] *Sent:* Tuesday, June 24, 2014 5:41 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Layer7 Switching - L7 Rule - comapre_type values I think the API should provide an richly featured interface, and individual drivers should indicate if they support the provided configuration. For example there is a spec for a Linux LVS LBaaS driver, this driver would not support TLS termination or any layer 7 features, but would still be valuable for some deployments. The user experience of such a solution could be improved if the driver to propagate up a message specifically identifying the unsupported feature. -Dustin On Tue, Jun 24, 2014 at 4:28 AM, Avishay Balderman avish...@radware.com wrote: Hi One of L7 Rule attributes is ‘compare_type’. This field is the match operator that the rule should activate against the value found in the request. Below is list of the possible values: - Regexp - StartsWith - EndsWith - Contains - EqualTo (*) - GreaterThan (*) - LessThan (*) The last 3 operators (*) in the list are used in numerical matches. Radware load balancing backend does not support those operators “out of the box” and a significant development effort should be done in order to support it. We are afraid to miss the Junu timeframe if we will have to focus in supporting the numerical operators. Therefore we ask to support the non-numerical operators for Junu and add the numerical operators support post Junu. See https://review.openstack.org/#/c/99709/4/specs/juno/lbaas-l7-rules.rst Thanks Avishay ___ 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] Layer7 Switching - L7 Rule - comapre_type values
Making sure all drivers support the features offered in Neutron LBaaS means we are stuck going with the 'least common denominator' in all cases. While this ensures all vendors implement the same things in the functionally the same way, it also is probably a big reason the Neutron LBaaS project has been so incredibly slow in seeing new features added over the last two years. In the gerrit review that Dustin linked, it sounds like the people contributing to the discussion are in favor of allowing drivers to reject some configurations as unsupported through use of exceptions (details on how that will work is being hashed out now if you want to participate in that discussion). Let's assume, therefore, that with the LBaaS v2 API and Object model we're also going to get this ability-- which of course also means that drivers do not have to support every feature exposed by the API. (And again, as Dustin pointed out, a Linux LVS-based driver definitely wouldn't be able to support any L7 features at all, yet it's still a very useful driver for many deployments.) Finally, I do not believe that the LBaaS project should be held back because one vendor's implementation doesn't work well with a couple features exposed in the API. As Dustin said, let the API expose a rich feature set and allow drivers to reject certain configurations when they don't support them. Stephen On Tue, Jun 24, 2014 at 9:09 AM, Dustin Lundquist dus...@null-ptr.net wrote: I brought this up on https://review.openstack.org/#/c/101084/. -Dustin On Tue, Jun 24, 2014 at 7:57 AM, Avishay Balderman avish...@radware.com wrote: Hi Dustin I agree with the concept you described but as far as I understand it is not currently supported in Neutron. So a driver should be fully compatible with the interface it implements. Avishay *From:* Dustin Lundquist [mailto:dus...@null-ptr.net] *Sent:* Tuesday, June 24, 2014 5:41 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Layer7 Switching - L7 Rule - comapre_type values I think the API should provide an richly featured interface, and individual drivers should indicate if they support the provided configuration. For example there is a spec for a Linux LVS LBaaS driver, this driver would not support TLS termination or any layer 7 features, but would still be valuable for some deployments. The user experience of such a solution could be improved if the driver to propagate up a message specifically identifying the unsupported feature. -Dustin On Tue, Jun 24, 2014 at 4:28 AM, Avishay Balderman avish...@radware.com wrote: Hi One of L7 Rule attributes is ‘compare_type’. This field is the match operator that the rule should activate against the value found in the request. Below is list of the possible values: - Regexp - StartsWith - EndsWith - Contains - EqualTo (*) - GreaterThan (*) - LessThan (*) The last 3 operators (*) in the list are used in numerical matches. Radware load balancing backend does not support those operators “out of the box” and a significant development effort should be done in order to support it. We are afraid to miss the Junu timeframe if we will have to focus in supporting the numerical operators. Therefore we ask to support the non-numerical operators for Junu and add the numerical operators support post Junu. See https://review.openstack.org/#/c/99709/4/specs/juno/lbaas-l7-rules.rst Thanks Avishay ___ 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 -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
