Open Stack

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>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.



>  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.)

>  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.)


>
>
> 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/20140501/5f1b708a/attachment.html>