After switching to Search Head cluster some of our team members are having hard time adjusting to the 'deployment of the searches, alerts and dashboards' idea and modify those searches directly through web GUI which results in local delta of the objects stored on the cluster member and future deployment of the updated objects is being overwritten by those local copies.
Example:
- I have an HTML dashboard that references "Saved Search A" deployed to the cluster on the deployment server.
- Deployed configs to the cluster members
- Changes have been made to that dashboard via GUI referencing "Saved Search B"
- For the next deployment I reference "Saved Search C", but it is being ignored as the local copy references B
How do you go around "sanitizing" those local changes to override the local copies?
Thanks!
A couple of points:
The search head cluster is designed to allow users to directly change dashboards and other knowledge objects. Those changes are then replicated automatically to the other members of the cluster. So, what your users are doing sounds fine.
The deployer is meant for distributing baseline configurations, such as migrated settings or upgraded apps. Once the app has been deployed to the members, most future changes, such as the types of dashboard changes that you describe, occur automatically through configuration replication.
Use the deployer, not the deployment server, to distribute apps and such to the cluster members.
For more information, see the set of three topics that discuss cluster member updates, starting with this one:
http://docs.splunk.com/Documentation/Splunk/6.4.2/DistSearch/HowconfigurationworksinSHC
These sections in particular address some of your main concerns:
in SHC after your initially migrate from pooling, you should either manage objects through GUI or Deployer but not both. Local copy always override default.