Deployment Architecture

Apps: To Disable or To Delete?

oreoshake
Communicator

I'm setting up a deployment server. From what I understand, the deployment server only adds or updates app files and doesn't delete them. Is it "better" to delete the apps we don't want to use, or just disable them? It seems like it would be more efficient to delete the directories for smaller deployment bundles (and in theory quicker updates) and less disk footprint.

1 Solution

Lowell
Super Champion

I feel like deleting is the cleaner approach, however there is a downside if you are talking about pre-distributed apps (like Splunk*Forwarder or sample_app). If you simple delete these apps, then next time you install a Splunk upgrade, these apps will get re-installed and may be enabled again (depending on their default packaged state.) However, if you had simple disabled these apps, the apps would have stayed disabled because the upgrade preserves that preference. (The local folder is not overwritten during the upgrade.)

We do this with the deployment process by creating a dummy (empty) application that contains only the local/app.conf file, which has the following content:

[install]
state = disabled

This way the app is removed initially, and if an upgrade occurs, at least the app does not get enabled again. Of course, I kind of liked the 3.x model for this slightly better, where one app could actually disable another app, but I also see how that could create other problems. At the moment, I think this is the "best" approach.

BTW, thanks to gkanapathy for pointing out this idea to me in the first place: http://www.splunk.com/support/forum:SplunkAdministration/4172

View solution in original post

Lowell
Super Champion

I feel like deleting is the cleaner approach, however there is a downside if you are talking about pre-distributed apps (like Splunk*Forwarder or sample_app). If you simple delete these apps, then next time you install a Splunk upgrade, these apps will get re-installed and may be enabled again (depending on their default packaged state.) However, if you had simple disabled these apps, the apps would have stayed disabled because the upgrade preserves that preference. (The local folder is not overwritten during the upgrade.)

We do this with the deployment process by creating a dummy (empty) application that contains only the local/app.conf file, which has the following content:

[install]
state = disabled

This way the app is removed initially, and if an upgrade occurs, at least the app does not get enabled again. Of course, I kind of liked the 3.x model for this slightly better, where one app could actually disable another app, but I also see how that could create other problems. At the moment, I think this is the "best" approach.

BTW, thanks to gkanapathy for pointing out this idea to me in the first place: http://www.splunk.com/support/forum:SplunkAdministration/4172

stefan1988
Path Finder

Bear in mind that once an app state = disabled and you try to remove the app by deleting it from the shcluster apps on the deployment server the app won't be removed on the search heads because it's state is disabled.

0 Karma

gkanapathy
Splunk Employee
Splunk Employee

Deployment Server synchronizes entire app folder contents by adding, deleting, or otherwise changing, and it will also remove apps that were removed from Deployment Server configuration. It doesn't matter very much whether you delete or disable apps, your preference.

0 Karma
Career Survey
First 500 qualified respondents will receive a $20 gift card! Tell us about your professional Splunk journey.

Can’t make it to .conf25? Join us online!

Get Updates on the Splunk Community!

Splunk Lantern’s Guide to The Most Popular .conf25 Sessions

Splunk Lantern is a Splunk customer success center that provides advice from Splunk experts on valuable data ...

Unlock What’s Next: The Splunk Cloud Platform at .conf25

In just a few days, Boston will be buzzing as the Splunk team and thousands of community members come together ...

Index This | How many sevens are there between 1 and 100?

August 2025 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with this ...