Deploying different apps based on the clients build or version number?

[Lowell]

Anyone know if it's possible to deploy different apps based on the clients build or version number?

I thought I had read this feature is not yet supported online, but I found the following entry in the serverclass.conf docs, so now I'm not sure:

Copied from $SPLUNK_HOME/etc/system/README/serverclass.conf.spec:

# Properties that you may want to typically override at this level include:
# repositoryLocation
# continueMatching
# filtering using whitelist/blacklist, startBuild, endBuild, machineType
# requiresRestart
# stateOnClient

The terms startBuild and endBuild grabbed my attention, but they are not defined anywhere else in the spec file. Anyone know if these are legit or just leftovers that should be removed from the docs? (Also, the build numbers don't seem to go in a helpful order. They seem to be based more when they were build and don't correlate to a x.y version number, which would be more useful.)

Right now I have a mix of 4.0 and 4.1 deployment clients and there is just enough of a config file difference between the two releases (such as tags.conf and the usage of _TCP_ROUTING=* in inputs.conf) that I'll need to maintain two versions until I can get all the deployment clients upgraded to 4.1. So I'm trying to figure out how to make this as painless as possible. Any ideas?

[ftk]

I just ran a test using startBuild and endBuild as filters in my serverclass.conf. I deployed appA to 4.0.1 clients and appB to 4.1.2 clients, builds 64658 and 79191 respectively.

You can get the build numbers from here: http://www.splunk.com/page/previous_releases. The build number is in the file name. In this file for example, splunk-4.0.2-64889-linux-2.6-intel.deb, the build number is 64889.

Example serverclass.conf

[global]

[serverClass:buildAppTest]
whitelist.0=*

[serverClass:buildAppTest:app:appA]
startBuild=64658
endBuild=64658

[serverClass:buildAppTest:app:appB]
startBuild=79191 
endBuild=79191 

[Lowell]

Yeah, this didn't actually work for me. I gave up and just created two deployment classes using whitelists based on host names. I've been manually moving the hosts between the two classes by hand, running splunk reload deploy-server and upgrading the forwarders... (It's a pain, but at least it works.)

[Lowell]

Thanks for the info. Looks like the docs should be updated. Although, we'll see how manageable this is after a few more 4.0.x and 4.1.x releases with intermingled build numbers. (Oh, and I wrote a small script to create a table of build number vs. version number... I posted it here: (http://answers.splunk.com/questions/2068/splunk-build-number-to-version-table/2104#2104)