Adam, you are correct to show why order matters in policies.
It is a good point to consider AND between rules.
If you really want to OR rules you can use different policies.
Stephen, the need for order contradicts using content modification with the
same API since for modification you would really want to evaluate the whole
list.
Regards,
-Sam.
On 2 במאי 2014, at 06:15, "Adam Harwell"
<[email protected]<mailto:[email protected]>> wrote:
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 <[email protected]<mailto:[email protected]>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<[email protected]<mailto:[email protected]>>
Date: Thursday, May 1, 2014 6:52 PM
To: "OpenStack Development Mailing List (not for usage questions)"
<[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>> 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<http://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<http://mysite.com/hello/index.htm>" and direct it
to Pool A, while "mysite.com/hello/nope.htm<http://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<http://mysite.com>" ] } directs to Pool B
In that case, it would match
"mysite.com/hello/nope.htm<http://mysite.com/hello/nope.htm>" on the second
policy, still directing to Pool A.
In both cases, "mysite.com/hi/<http://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
_______________________________________________
OpenStack-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
