Data Groups for dummies

adding this example to the class command page for future reference.

I also wrote up a tech tip on this to clarify all the formats:

 

 

http://devcentral.f5.com/Tutorials/TechTips/tabid/63/articleType/ArticleView/articleId/1086448/iRules-Data-Group-Formatting-Rules.aspx Click Here

Posted By hoolio on 03/18/2011 08:47 AM

Hi Kent,

That looks like a great start. You don't actually have to iterate through the datagroup manually to do a starts_with comparison. You can use class search to do this:

when RULE_INIT {

 Log debug to /var/log/ltm? 1=yes, 0=no
set static::debug 0
}
when CLIENT_ACCEPTED {

 Save the VS default pool name before it's changed
set default_pool "defpool01"

 set the data group name
set clname "AppVersion[virtual name]"
}
when HTTP_REQUEST {

 if there isn't a data group with the above name, set the pool to default and exit
if {[class exists $clname]} {

 Search the datagroup for a name that starts with the URI
set pool_name [class search -value $clname starts_with [HTTP::uri]]

if { $pool_name eq ""} {
 we don't match the context roots in the data class
if { $static::debug } { log local0. "fell through to the default pool" }
pool $default_pool
} else {
if { $static::debug } { log local0. "Matched $app_pool" }
pool $app_pool

}
} else {
if { $static::debug } { log local0. "Data group $clame not found, using default_pool $default_pool" }
pool $default_pool
}
}

Aaron

I'm back. I am testing this iRule and it does not appear to work. The pool_name variable does not appear to be set if my URI is, as I put it on the command line, ends with a / For example, if my data group looks like:

/foo2_1 := foo21
/foo2_2 := foo22

and I try to hit the virtual server with curl like this, curl http://10.10.10.100/foo2_1/, pool_name does not get set, and I fall through to the default pool, but nothing happens and the connection gets reset by peer. FYI, this is running on LTMVE, 10.2.0. Now, I don't think the connection getting reset has anything to do with the iRule. Is there anyway to see inside the line "set pool_name [class search -value....]" to find out what it happening there? If I add the trailing slash to the data group, /foo2_1/ instead of /foo2_1, pool_name sets set.

Also, app_pool is not used anyplace but in the log statement and where you set the pool to $app_pool. I have changed that to $pool_name.

Again, thanks for your help!

Kent

Can you try this instead:

 

 

log local0. "[class match -value [HTTP::uri] starts_with $clname]"

 

 

Aaron

I am assuming that you swapped the [HTTP::uri] and $clname by accident.

 

 

My uneducated opinion leads me to believe that the starts_with operator does an exact match and since I don't have the trailing / in the data group, it does not find anything and that class match operation returns a null value. Not that it will be a big deal, as the clients accessing the virtual server will be including the trailing slash. The simplest solution will be to update the data groups to include the trailing slash. Its odd that my original script did not exhibit this behavior. Perhaps you have the tools to look inside of the class search operation to see what is happening there.

No, it's not particularly intuitive, but the class match command will work:

 Datagroup
class uri_prefixes_class {
   {
      "/foo1" { "pool1" }
      "/foo2" { "pool2" }
   }
}

 iRule example
when RULE_INIT {

log local0. "\[class search -value uri_prefixes_class starts_with \"/foo123\"\]: [class search -value uri_prefixes_class starts_with "/foo123"]"
log local0. "\[class match -value \"/foo123\" starts_with uri_prefixes_class\]: [class match -value "/foo123" starts_with uri_prefixes_class]"
}
/var/log/ltm output:
< RULE_INIT >: [class search -value uri_prefixes_class starts_with "/foo123"]:
< RULE_INIT >: [class match -value "/foo123" starts_with uri_prefixes_class]: pool1

Aaron

I believe the issue Aaron's outlining above, whether intentionally or not, is one major way in which class match and class search differ: order of operands.

class match [< options >] < item > < operator > < class >class search [< options >] < class > < operator > < item >Note that in the above the  and  positions are switched. This indicates an implicit difference in the way the lookup is performed. This is further outlined in the examples in the wiki: 

* Example:

o class match [HTTP::uri] ends_with image_class

o read as, does the URI end with an element from image_class.

vs

* Example:

o class search blocked_paths starts_with [HTTP::uri]

o read as, does blocked_paths contain an element that starts with the URI.

Note that in the search, you're searching the class for something that starts with the string, rather than comparing the string to each to see if it matches (or starts with) one of the contained class entries. This is a very important difference depending on circumstances.

Hopefully that makes sense. üòâ

Colin

...

Ah. I guess its too much effort to be consistent in the placement of arguments for different options of the same higher level command? Or is this the case where developer A worked on class match and developer B worked on class search, and they didn't talk to each other?

 

 

I expected to be in the same order. After all, why wouldn't they?

I actually think this is a desired (albeit sometimes confusing) difference. These are semantically very different things and being able to achieve either as desired is a good thing. That's just my hunch, though, I don't have the official answer as to why they're different. Just trying to fill folks in. ;)

 

 

Colin