Open Stack

My thoughts are inline (in red, since I can't figure out how to get Outlook to properly format the email the way I want).

From: Stephen Balukoff <sbalukoff at bluebox.net<mailto:sbalukoff at bluebox.net>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Thursday, May 1, 2014 6:52 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS]L7 conent switching APIs

Hi Samuel,

We talked a bit in chat about this, but I wanted to reiterate a few things here for the rest of the group.  Comments in-line:


On Wed, Apr 30, 2014 at 6:10 AM, Samuel Bercovici <SamuelB at radware.com<mailto:SamuelB at radware.com>> wrote:
Hi,

We have compared the API the is in the blue print to the one described in Stephen documents.
Follows the differences we have found:

1)      L7PolicyVipAssoc is gone, this means that L7 policy reuse is not possible. I have added use cases 42 and 43 to show where such reuse makes sense.

Yep, my thoughts were that:

  *   The number of times L7 policies will actually get re-used is pretty minimal. And in the case of use cases 42 and 43, these can be accomplished by duplicating the L7policies and rules (with differing actions) for each type of connection.
  *   Fewer new objects is usually better and less confusing for the user. Having said this, a user advanced enough to use L7 features like this at all is likely going to be able to understand what the 'association' policy does.

The main counterpoint you shared with me was (if I remember correctly):

  *   For different load balancer vendors, it's much easier to code for the case where a specific entire feature set that isn't available (ie. L7 switching or content modification functionality) by making that entire feature set modular. A driver in this case can simply return with a "feature not supported" error if anyone tries using L7 policies at all.

 I agree that re-use should not be required for L7 policies, which should simplify things.

2)      There is a mix between L7 content switching and L7 content modification, the API in the blue print only addresses L7 content switching. I think that we should separate the APIs from each other. I think that we should review/add use cases targeting L7 content modifications to the use cases document.

Fair enough. There aren't many such use cases in there yet.

a.                   You can see this in L7Policy: APPEND_HEADER, DELETE_HEADER actions

3)      The action to redirect to a URL is missing in Stephen’s document. The 'redirect' action in Stephen’s document is equivalent to the “pool” action in the blue print/code.

Yep it is. But this is actually pretty easily added.  We would just add the 'action' of "URL_REDIRECT" and the action_argument would then be the URL to which to redirect.


4)      All the objects have their parent id as an optional argument (L7Rule.l7_policy_id, L7Policy.listener_id), is this a mistake?

That's actually not a mistake--  a user can create "orphaned" rules in this model. However, the point was raised earlier by Brandon that it may make sense for members to be child objects of a specific pool since they can't be shared. If we do this for members, it also makes sense to do it for L7Rules since they also can't be shared. At which point the API for manipulating L7Rules would shift to:

/l7_policy/{policy_uuid}/l7_rules

And in this case, the parent L7Policy ID would be implicit.

(I'm all for this change, by the way.)

Sounds good to me too!

5)      There is also the additional behavior based on L3 information (matching the client/source IP to a subnet). This is addressed by L7Rule.type with a value of 'CLIENT_IP' and L7Rule.compare_type with a value of 'SUBNET'. I think that using Layer 3 type information should not be part of L7 content switching as the use cases I am aware of, might require more than just selecting a different pool (ex: user with ip from internet browsing to an https based application, might need to be secured using 2K SSL keys while internal users could use weaker keys)

While it's true that having a way to manipulate this without being part of an HTTP or unwrapped HTTPS session is also useful--  it's still useful to be able to create L7 rules which also make decisions based on subnet.  (Notice also with TLS_SNI_Policies there is a 'hostname' attribute, and also with L7 rules there is a 'hostname' type of rule? Again, useful to have in two places, eh!)

I would like to state that although the WIKI describes the solution from a high level it is not totally in sync with the actual code.
The key thing which is missing is that, L7 Policies in a specific listener/vip are ordered (ordered list) and are processed in order so that the 1st policy that has a match will be activated and traversal of the L7 policy list is topped as the processing is final (ex: redirect, pool, reject).
This in effect means that L7 Policy form an ‘or’ condition between them.
L7 Policies have an ordered list of L7 Rules, L7 Rules are processed by this order and also form an ‘or’ condition.

Agreed, and I think my API works the same way. I will say though:  I did remove the 'order' attribute from L7Rules because if all the conditions that make up a policy are OR'ed together, then order no longer matters.  If we want to define a more feature-rich DSL here, then rule order would matter.  (Note that the order in which entire L7Policies appear still matters. The first one to match wins in the case of a 'redirect' match, eh.)

Stephen, the way I understood your API proposal, I thought you could essentially combine L7Rules in an L7Policy, and have multiple L7Policies, implying that the L7Rules would use AND style combination, while the L7Policies themselves would use OR combination (I think I said that right, almost seems like a tongue-twister while I'm running on pure caffeine). So, if I said:
 * The policy { rules: [ rule1: match path REGEX ".*index.*", rule2: match path REGEX "hello/.*" ] } directs to Pool A
 * The policy { rules: [ rule1: match hostname EQ "mysite.com" ] } directs to Pool B
then order would matter for the policies themselves. In this case, if they ran in the order I listed, it would match "mysite.com/hello/index.htm" and direct it to Pool A, while "mysite.com/hello/nope.htm" would not match BOTH rules in the first policy, and would be caught by the second policy, directing it to Pool B. If I had wanted the first policy to use OR logic, I would have just specified two separate policies both pointing to Pool A:
 * The policy { rules: [ rule1: match path REGEX ".*index.*" ] } directs to Pool A
 * The policy { rules: [ rule1: match path REGEX "hello/.*" ] } directs to Pool A
 * The policy { rules: [ rule1: match hostname EQ "mysite.com" ] } directs to Pool B
In that case, it would match "mysite.com/hello/nope.htm" on the second policy, still directing to Pool A.
In both cases, "mysite.com/hi/" would only be caught by the last policy, directing to Pool B.
Maybe I was making some crazy jumps of logic, and that's not how you intended it? That said, even if that wasn't your intention, could it work that way? It seems like that allows a decent amount of options… :)

     --Adam

Regards,
                -Avishay, Evgeny and Sam




--
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/20140502/80dff441/attachment.html>