so i just want to clarify somethings:
app deployed: test_app
directories: Default, Local
Local: no files
what happens if i make the following changes to the app on the client:
1)modify the file in default -> test_app/default/inputs.conf
Will changes be ovewritten?
2)create a file in local -> test_app/local/inputs.conf
Will changes be ovewritten, ie file deleted?
3)create a new file in default -> test_app/default/props.conf
Will changes be ovewritten, ie file deleted?*
IF there was some config in the local directory on th Deployment server ie
4) would the config in local even get deployed?
5) modify the deployed file in local -> test_app/default/savedseraches.conf
Will changes be ovewritten by orginal savedsearcjes.conf on the DS?
Are no changes overwritten until the app and therefore hash is changed on DS itself?!
if it is will that overwrite local?
Can someone clear this up? Thanks!!
Please see the
excludeFromUpdate option in serverclass.conf configuration option that's available in Splunk 6.2 and later.
Copied from the docs:
# Example 4 # Specify app update exclusion list. [global] # The local/ subdirectory within every app will not be touched upon update. excludeFromUpdate=$app_root$/local [serverClass:MyApps] [serverClass:MyApps:app:SpecialCaseApp] # For the SpecialCaseApp, both the local/ and lookups/ subdirectories will # not be touched upon update. excludeFromUpdate=$app_root$/local,$app_root$/lookups
This isn't working as desired for us, ATM. One of my App guys is having problems were savedsearches.conf in /local is being merged/appended into savedsearches.conf in /default when we've used the excludeFromUpdate option for $app_root$/local. I've verified that this happens on the Search Head. The contents of the bundles are correct on both the deployment server and the search head.
The deployment server will overwrite everything - the entire app folder - if any changes are made within the folder.
Basically, the client creates a hash of the folder, and the deployment server creates a hash of the folder. If the system checks the hashes and finds they are different the the server sends the folder to the client.
I can see how this algorithm works (in a depth-first-search manner).
The question I have is with the my-app/local directory.
The client has client-specific stuff in my-app/local such as the savedsearches.conf file
in our etc/deployment-apps/my-app/local we do not have a savedsearches.conf file so I'm expecting that the client's local directory's own savedsearches.conf file won't be obliterated during a deploy.
But that seems to be what is happening.
By your logic, the local directory's hash will be different and if the deployment simply obliterates the local directory and copies down the new local directory...then indeed I can see how we loose our local/savedsearches.conf file.
If however, the deployment overlays the my-app/local with the my-app/local that is in the etc/deployment-apps/my-app/local then we would get the behavior I am looking for where the client's savedsearches.conf file will be maintained intact.
Unfortunately yes. You cannot use DS in this instance on search head as saved changes would get overwritten by DS.
DS needs an enhancement to exclude set of directories/files when updating app.
Just a comment to the above answers
This does NOT apply to user directories!
Only configurations of apps that are contained within the ./etc/apps/ dir on the search head will ever be touched.
What this means is that you can* use it to manage visual apps, you just have to be quite careful and have some other means to manage your local changes.
Users can : update their own dashboards, savedsearches etc and an app deployment will not effect their files (all contained within the users dirs.
However, if an admin/power user changes the permissions on a dashboard/savedsearch and makes them public they are actually copied to the app and then also deleted from the users home dir!
What we have been doing is if a user wants to make their app public we make a clone of it and make it public. We can keep them as the owner they can still make changes to the dashboard.
Once this is done these changes also need to be replicated back into your deployment server repo. If that app updates and pushes out it will replace/delete that PUBLIC dashboard.
As a side note in v6.2 the "deploy server" (different to deployment server!) has smarts in which it combines local and default dirs together. These end up in the default dir on the search head. ( http://docs.splunk.com/Documentation/Splunk/latest/DistSearch/PropagateSHCconfigurationchanges#What_...).