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

Samuel Bercovici SamuelB at Radware.com
Wed Feb 12 20:48:12 UTC 2014


Hi Stephen,

See embedded response bellow.

Regards,
                -Sam.

From: Stephen Balukoff [mailto:sbalukoff at bluebox.net]
Sent: Wednesday, February 12, 2014 8:46 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Proposal for model change - Layer 7 support

Howdy, Sam!

Thanks also for your speedy response.  Comments / additional questions are in-line below:

On Wed, Feb 12, 2014 at 2:51 AM, Samuel Bercovici <SamuelB at radware.com<mailto:SamuelB at radware.com>> wrote:
<Sam> We have reviewed this based on capabilities that we belive could be supported by HA proxy and all commercial vendors.
<Sam> What is missing?
Nothing major that I could see--  I was mostly curious where the discussion took place and whether it was documented anywhere. (Again, I'm still in the process of catching up with the goings on of this project, and understand LBaaS features of Neutron have been under development for a couple years now. Doing forensics to find out this sort of thing is often tedious and fruitless-- it's usually quicker just to ask.)


  *   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?
<Sam> Correct.

  *   Shouldn't the L7Rule object also have a l7PolicyID attribute?
<Sam> It does.
Excellent! I've updated the wiki page to reflect this. :)  I shall also be endeavoring to produce an updated diagram, since I think a picture can save a lot of words here, eh. :)


  *   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!).
<Sam> Correct the L7VIPPollicyassociation should have a “position” attribute. The way to implement is under consideration.
Cool. Are the solutions being considered:

1. Make it at additional integer attribute of the L7VIPPolicyAssociation object. (The side effect of this is that any given L7VIPPolicyAssociation object can only be associated with one VIP.)
<Sam> We are looking to use an integer attribute so that the combination of vip-id + ordinal number governs the order per vip. Alternatively we might just add a float column so that you can control the ordering by specifying some arbitrary floating number and the sort order will be vip + ordinal column.

2. Create an additional association object to associate the L7VIPPolicyAssociation with a VIP (ie. a join table of some kind), which carries this position attribute and would allow a given L7VIPPolicyAssociation to be associated with multiple VIPs.

FWIW, I think of the above, only number 1 really makes sense. The point of the L7VIPPolicyAssociation is to associate a VIP and Pool, using the rules in a L7Policy. All that L7VIPPolicyAssociation is missing is a position attribute.

As an aside, when you say, "under consideration," exactly how / where is it being considered?  (Again, sorry for my newbishness-- just trying to figure out how this body makes these kinds of decisions.)
<Sam> see response above.


  *   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.
<Sam> nope this any to any. Pools can be associated with multiple VIPs
Thanks for the clarification!

  *   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.
<Sam> the “default” behavior is governed by the current VIP --> Pool relationship. This is the canonical approach that could also be addressed by LBaaS drivers that do not support L7 content switching.
<Sam> We will fix the VIP<---->Pool limitation (for Juno) by removing the Pool-->VIP reference al only leaving the VIP --> Pool reference thus allowing the Pool to be used by multiple VIPs. This was originally planned for icehouse but will be handle for Juno.


Aah--  Ok, I thought that based on recent discussions in the IRC meetings that the L7 features of LBaaS were very unlikely to make it into Icehouse, and therefore any discussion of them was essentially a discussion about what's going to go into Juno.  If this isn't the case, could we get a little more clarification of exactly what features are still being considered for Icehouse?

In any case, you're right that relying on the legacy Pool-->VIP association to define the 'Default backend' configuration means that a given pool can be the default backend for only one VIP. I therefore think it makes a whole lot of sense to scrap that entirely when the L7 features are introduced.

The model here: https://wiki.openstack.org/w/images/e/e1/LBaaS_Core_Resource_Model_Proposal.png
...doesn't seem to reflect a PoolID attribute, and therefore it is not obvious that a VIP --> Pool association exists. This would be one way to define that default backend. Though it is a little uglier, in my opinion, because, for example, to figure out which VIPs need updating on the load balancers when a given pool object changes, we now have to not only look for all the L7VIPPolicyAssociations referencing the given pool, but also all the VIP objects which reference the pool. In my opinion it would be cleaner if VIPs and Pools could *only* be associated with each other via a L7VIPPolicyAssociation (and just have a special one of these defining that 'DEFAULT' VIP to Pool association.)


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.
<Sam> It is not HA proxy specific as all commercial implementation can support this.

My point is that we're defining this stuff in a configuration format that is very haproxy specific. So if you're a vendor with your own language for defining L7 rules and associations, you will need to be versant in haproxy's way of defining these in order to translate them into your own language.

Not that there's anything wrong with this, per se:  We've got to have some kind of language for defining L7 rules and associations, so why not use that of a very popular, well tested, and completely open source project? It certainly beats defining our own pseudo language right now, eh. *shrug*  And frankly, if I were doing this kind of thing solo, this is exactly the same choice I would make.

For what it's worth, I don't actually represent any given load balancer vendor, and don't really have plans to create drivers for any particular proprietary load balancer. (The only driver I plan on working on is for the software appliance model I already discussed-- and this is based on haproxy already.) I guess I only bring this up so that it's clear to everyone working on this project and any load balancer vendors thinking of getting involved with Neutron LBaaS that because of the configuration format we're choosing to go with for L7 rules and associations, we're inherently going to have an haproxy bias. :)

And again, I'm OK with this. :)

Thanks,
Stephen


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


More information about the OpenStack-dev mailing list