Is it possible to do a "dry-run" of a serverclass config, to see how it will actually deploy?
Ie. which clients would be in which classes, and which apps would they receive?
Something like this is not readily available. You can create a blank app (only with app.conf file or any insignificant configuration entry) for each of the app you want to deploy through serverclass and they can use Forwarder Management dashboard to see what apps will go to what clients. Little bit of additional work but should do the trick. Once validated, you can copy the actual app back.
Do you think Forwarder Management view will help ?
(ref: http://docs.splunk.com/Documentation/Splunk/6.5.0/Updating/Forwardermanagementoverview)
Yes, in cases where you can populate the DEV env with the same combination of different forwarders (not necessarily the same number), that's an option. For some of our more streamlined operations, that would be OK. But in this case we're talking about a rather heterogenerous environment that's hard to replicate.
The simulator approach mikaelbje alludes to would be our best bet, I think.
As you can see in this discussion, there is no feature in Splunk fits in what you are looking for. I knew it 🙂
I simply pointed out available feature which may or may not help. And, it is glad to see this further discussion for the question.
Yes, I agree with @mikaelbje, dev. environment with closest settings to prod. is a general approach if we cannot do in prod env.
If you're looking for this feature in Splunk, please file an enhancement request with use cases.
Thanks, but unfortunately not.
It helps with some things. For instance, we deploy empty server classes (no apps), and then we can see which forwarders match which classes.
But in our specific case, we need to replace a "blacklist" default config with a "whitelist" default config. This means completely replacing the serverclass file. And that's not possible like that.
How about a DEV environment? Use dev then push to production...
Set up a dev env with the same amount of forwarders? I believe the OPs question is how to test the matching/non-matching of server classes, particularly in combination with continueMatching, not whether an app works or not. That scenario is well suited for a test env, but the one where you need to test the behaviour of Deployment Server as a whole is not suited for a test env.
If only we could simulate N amount of forwarders with specific names/DNS entries/IP addresses/ClientNames...