[openstack-dev] [Neutron][LBaaS] Proposal for model change - Layer 7 support

Stephen Balukoff sbalukoff at bluebox.net
Wed Feb 12 09:58:05 UTC 2014


Hi Samuel!

Per your request, here's some feedback on the layer 7 proposal referenced
below. Please let me know if by "comment is something missing there" you
meant I should actually comment within the blueprint or wiki system instead
of in this e-mail thread.


   - Are L7Policy, L7Rule, and L7VipPolicyAssociation all new resources
   within the data model, or are any of these simply going to be implemented
   as additional fields to existing objects? (I'll try to produce a new
   diagram for y'all illustrating how these fit in with the existing data
   model, unless one of you has this already.)

   - I see the intent is to support L7 rules of the following types: "Hostname,
   Path, File Type, Header, Cookie" Has there been discussion around
   supporting other types of L7 rules?  (I ask mostly out of curiosity-- the
   list there actually covers the 90% use case for our customers just fine.)

   - Since the L7Rule object contains a position indicator, I assume,
   therefore, that a given L7Rule object cannot exist in more than one
   L7Policy, correct?  Also, I assume that the first L7Rule added to an
   L7Policy becomes the rule at position 0 and that subsequent rules are added
   with incrementing positions. This is unless the position is specified, in
   which case, the rule is inserted into the policy list at the position
   specified, and all subsequent rule position indicators get incremented.
   Correct?

   - Shouldn't the L7Rule object also have a l7PolicyID attribute?

   - It is unclear from the proposal whether a given VIP can have
multiple L7VipPolicyAssociation
   objects associated with it. If not, then we've not really solved the
   problem of multiple back-end pools per VIP. If so, then the
   L7VipPolicyAssociation object is missing its own 'position' attribute
   (because order matters here, too!).

   - I assume any given pool can have multiple L7VipPolicyAssociations. If
   this is not the case, then a given single pool can only be associated with
   one VIP.

   - There is currently no way to set a 'default' back-end pool in this
   proposal. Perhaps this could be solved by:
   - Make 'DEFAULT' one of the actions possible for a L7VipPolicyAssociation
      - Any L7VipPolicyAssociation with an action of 'DEFAULT' would have a
      null position and null L7PolicyId.
      - We would need to enforce having only one L7VipPolicyAssociation
      object with a 'DEFAULT' action per VIP.


Other than the last three points above, the L7Policy, L7Rule, and
L7VipPolicyAssociation do essentially the same thing as the 'ACL' object in
my proposal, albeit with more granularity in the objects themselves. (In
our BLBv2 implementation, we have pretty loose rules around what can be
specified in a given ACL, and allow haproxy to do syntax checking itself on
the whole generated configuration file, returning an error and refusing to
update a listener's in-production configuration until the error is resolved
in the case where the user made an error on any given ACL.)  I like that in
this proposal, the model seems to enforce compliance with certain rule
formats, which, presumably, could be syntax checked against what haproxy
will allow without having to call haproxy directly.

The down-side of the above is that we start to enforce, at the model level,
very haproxy-specific configuration terminology with this. This is fine, so
long as load balancer vendors that want to write drivers for Neutron LBaaS
are capable of translating haproxy-specific ACL language into whatever
rules make sense for their appliance.

Having said the above, I don't see a way to expose a lot of L7
functionality and still be able to do syntax checking without choosing one
particular configuration format in which rules can be specified (in our
case, haproxy).  I suppose we could invent our own pseudo rule language--
but why bother when haproxy has already done this, eh?

I'll take a look at the SSL stuff next, then the LoadBalancerInstance
stuff...

Thanks,
Stephen

On Tue, Feb 11, 2014 at 5:26 AM, Samuel Bercovici <SamuelB at radware.com>wrote:

> Please review the current work in progress and comment is something is
> missing there.
>
> The logical load balancer API which is already addressed:
>
> ·         Multiple pools per VIP (ie. “layer 7” support)       -
> https://blueprints.launchpad.net/neutron/+spec/lbaas-l7-rules.
>
>



-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140212/60f6bf93/attachment.html>


More information about the OpenStack-dev mailing list