<div dir="ltr">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.<div>
<br></div><div>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.</div>
<div><br></div><div>(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.)</div><div><br>
</div><div>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.</div>
<div><br></div><div>Stephen</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 24, 2014 at 9:09 AM, Dustin Lundquist <span dir="ltr"><<a href="mailto:dustin@null-ptr.net" target="_blank">dustin@null-ptr.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I brought this up on <a href="https://review.openstack.org/#/c/101084/" target="_blank">https://review.openstack.org/#/c/101084/</a>. <span class="HOEnZb"><font color="#888888"><div>
<br></div><div><br></div><div>-Dustin</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Jun 24, 2014 at 7:57 AM, Avishay Balderman <span dir="ltr"><<a href="mailto:AvishayB@radware.com" target="_blank">AvishayB@radware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi Dustin<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I agree with the concept you described but as far as I understand it is not currently supported in Neutron.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">So a driver should be fully compatible with the interface it implements.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Avishay<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Dustin Lundquist [mailto:<a href="mailto:dustin@null-ptr.net" target="_blank">dustin@null-ptr.net</a>]
<br>
<b>Sent:</b> Tuesday, June 24, 2014 5:41 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Neutron][LBaaS] Layer7 Switching - L7 Rule - comapre_type values<u></u><u></u></span></p><div><div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">-Dustin<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Tue, Jun 24, 2014 at 4:28 AM, Avishay Balderman <<a href="mailto:AvishayB@radware.com" target="_blank">AvishayB@radware.com</a>> wrote:<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">One of L7 Rule attributes is ‘compare_type’.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">This field is the match operator that the rule should activate against the value found in the request.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Below is list of the possible values:</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">- Regexp</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">- StartsWith</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">- EndsWith</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">- Contains</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">- EqualTo (*)</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">- GreaterThan (*)</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">- LessThan (*)</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The last 3 operators (*) in the list are used in numerical matches.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">We are afraid to miss the Junu timeframe if we will have to focus in supporting the numerical operators.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Therefore we ask to support the non-numerical operators for Junu and add the numerical operators
support post Junu. </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">See
<a href="https://review.openstack.org/#/c/99709/4/specs/juno/lbaas-l7-rules.rst" target="_blank">
https://review.openstack.org/#/c/99709/4/specs/juno/lbaas-l7-rules.rst</a></span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Avishay
</span><span style="color:#888888"><u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807
</div>