Open Stack

> 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.miramontes at 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 <sbalukoff at bluebox.net>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: Tuesday, June 24, 2014 7:30 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at 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 <dustin at 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 <AvishayB at 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:dustin at 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 <AvishayB at 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 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
>>
>>
>
>
>  --
> Stephen Balukoff
> Blue Box Group, LLC
> (800)613-4305 x807
>
>
> _______________________________________________
> 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/20140704/cddd3b0b/attachment.html>