> 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 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 > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev