Open Stack

Hi folks,

I think it's ok to include content modification in a general API proposal
as long as it would then receive separate spec document in neutron-specs.
When it comes to particular feature design and implementation it's better
to be more granular.

Thanks,
Eugene.



On Tue, May 6, 2014 at 4:05 AM, Stephen Balukoff <sbalukoff at bluebox.net>wrote:

> Hi Sam,
>
> In working off the document in the wiki on L7 functionality for LBaaS (
> https://wiki.openstack.org/wiki/Neutron/LBaaS/l7 ), I notice that
> "MODIFY_CONTENT" is one of the actions listed for a L7VipPolicyAssociation.
> That's the primary reason I included this in the API design I created.
>
> To be honest, it frustrates me more than a little to hear after the fact
> that the only locate-able documentation like this online is inaccurate on
> many meaningful details like this.
>
> I could actually go either way on this issue:  I included content
> modification as one possible action of L7Policies, but it is somewhat
> wedged in there:  It works, but in L7Policies that do content modification
> or blocking of the request, the order field as I've proposed it could be
> confusing for users, and these L7Policies wouldn't be associated with a
> back-end pool anyway.
>
> I'm interested in hearing others' opinions on this as well.
>
> Stephen
>
>
>
> On Mon, May 5, 2014 at 6:47 AM, Samuel Bercovici <SamuelB at radware.com>wrote:
>
>>  Hi Stephen,
>>
>>
>>
>> For Icehouse we did not go into L7 content modification as the general
>> feeling was that it might not be exactly the same as content switching and
>> we wanted to tackle content switching fiest.
>>
>>
>>
>> L7 content switching and L7 content modification are different, I prefer
>> to be explicit and declarative and use different objects.
>>
>> This will make the API more readable.
>>
>> What do you think?
>>
>>
>>
>> I plan to look deeper into L7 content modification later this week to
>> propose a list of capabilities.
>>
>>
>>
>> -Sam.
>>
>>
>>
>>
>>
>> *From:* Stephen Balukoff [mailto:sbalukoff at bluebox.net]
>> *Sent:* Saturday, May 03, 2014 1:33 AM
>>
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [Neutron][LBaaS]L7 conent switching APIs
>>
>>
>>
>> Hi Adam and Samuel!
>>
>>
>>
>> Thanks for the questions / comments! Reactions in-line:
>>
>>
>>
>> On Thu, May 1, 2014 at 8:14 PM, Adam Harwell <adam.harwell at rackspace.com>
>> wrote:
>>
>> 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:
>>
>>
>>
>> Well, my goal wasn't to create a whole DSL for this (or anything much
>> resembling this) because:
>>
>>    1. Real-world usage of the L7 stuff is generally pretty primitive.
>>    Most L7Policies will consist of 1 rule. Those that consist of more than one
>>    rule are almost always the sort that need a simple sort. This is based off
>>    the usage data collected here (which admittedly only has Blue Box's data--
>>    because apparently nobody else even offers L7 right now?)
>>    https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc&usp=sharing
>>    2. I was trying to keep things as simple as possible to make it
>>    easier for load balancer vendors to support. (That is to say, I wouldn't
>>    expect all vendors to provide the same kind of functionality as HAProxy
>>    ACLs, for example.)
>>
>>  Having said this, I think yours and Sam's clarification that different
>> L7Policies can be used to effective "OR" conditions together makes sense,
>> and therefore assuming all the Rules in a given policy are ANDed together
>> makes sense.
>>
>>
>>
>> If we do this, it therefore also might make sense to expose other
>> criteria on which L7Rules can be made, like HTTP method used for the
>> request and whatnot.
>>
>>
>>
>> Also, should we introduce a flag to say whether a given Rule's condition
>> should be negated?  (eg. "HTTP method is GET and URL is *not* "/api") This
>> would get us closer to being able to use more sophisticated logic for L7
>> routing.
>>
>>
>>
>> Does anyone foresee the need to offer this kind of functionality?
>>
>>
>>
>>   * 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:
>>
>>
>>
>> Clarification on this: There is an 'order' attribute to L7Policies. :)
>> But again, if all the L7Rules in a given policy are ANDed together, then
>> order doesn't matter within the rules that make up an L7Policy.
>>
>>
>>
>>    * 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
>>
>>
>>
>>
>>
>>
>>
>>  On Fri, May 2, 2014 at 4:59 AM, Samuel Bercovici <SamuelB at radware.com
>> > wrote:
>>
>>  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.
>>
>>
>>
>> Hi Sam, I was a bit confused on this point since we don't see users often
>> using both content modification and content switching in the same
>> configuration. However, checking the haproxy manual regarding content
>> modification rules:
>>
>>   - req* statements are applied after "block" statements, so that "block" is
>>
>>     always the first one, but before "use_backend" in order to permit rewriting
>>
>>     before switching.
>>
>>  And this in the 'use_backend' definition having to do with switching
>> based on L7 content:
>>
>>
>>
>>
>>
>> There may be as many "use_backend" rules as desired. All of these rules are
>>
>>   evaluated in their declaration order, and the first one which matches will
>>
>>   assign the backend.
>>
>>
>>
>> If this is true, this seem to imply that for HAProxy at least, order only
>> really matters for policies which switch back-ends. That is to say, all the
>> 'block' policies get processed first, followed by all the content
>> modification policies, followed by the switching policies. If you have two
>> conflicting content modification policies, what actually happens isn't
>> defined in the manual (though again-- why would anyone do this? Seems like
>> a scenario in which users shoot themselves in the foot.)
>>
>>
>>
>> Given this, it may make sense to enforce this order in our model somehow,
>> assuming other load balancer vendors would want to duplicate this behavior.
>> Otherwise, users might be confused why (for example) a modification rule is
>> applying a header to a request when that policy comes after a switching
>> policy in the overall list of policies. (One could do this by always
>> inserting new 'block' policies in order before any 'modification' policies,
>> and 'modification' policies before any 'redirect' policies, and not
>> allowing any API updates to move any rules in a way that would violate this
>> order.) Or, we could make that 'order' attribute only allowed (and
>> necessary) for 'redirect' policies-- the implication being no order applies
>> to block or content modification policies because they always get processed
>> first.
>>
>>
>>
>> We could do this by splitting modification, block, and switching L7
>> policy types into their own separate objects (all of which would have
>> similar 'rule' semantics), but I'm really not seeing a compelling reason to
>> do so.  (Again, I'm usually in favor of introducing fewer new objects.)
>>
>>
>>
>> What seems like the least confusing thing to do for the user?  What are
>> others' thoughts on this?
>>
>>
>>
>> Thanks,
>>
>> Stephen
>>
>>
>>
>>
>>
>> --
>> Stephen Balukoff
>> Blue Box Group, LLC
>> (800)613-4305 x807
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Stephen Balukoff
> Blue Box Group, LLC
> (800)613-4305 x807
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140507/d7ea2a41/attachment.html>