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 <sbaluk...@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 <samu...@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:sbaluk...@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.harw...@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 <samu...@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@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
