Are there best practices on preserving a custom app's local configuration?

[sloshburch]

Here's the scenario:

Assume I have a custom app - let's call it "customApp" - which is managed by my deployment server and pushed out to my search heads (deployment clients).

Unbeknownst to me, a user modified one of customApp's default knowledge objects from within the UI - let's pretend it was a macro (customApp/default/macros.conf). Therefore, this updated version of the macro now lives in the customApp/local/macros.conf - not in the etc/user/UserName/customApp/local/macros.conf

Soon after, on the deployment server, I've updated some other knowledge objects within the customApp (without updating the macro) and then reloaded the deployment server. That means the corrected macro in customApp/local/macros.conf is blown away during the deployment client (search head's) reload of the customApp.

Anyone have any tips or best practices on how to manage this configuration conundrum?

Lemme know if my story is unclear.

[s2_splunk · Accepted solution]

Deployment server does exactly what it's supposed to do. 🙂

I think the only answer is: If you want to allow users to make changes to apps on a search head that is a deployment client, you are approaching it the wrong way.
Why do you give your 'write' access to the app, should they be able to make changes? If not, you can prevent this from happening by removing the 'write' privilege from the relevant roles in the permissions for the app.

If they need to have the ability to change an app managed by a deployment server, I don't see a way other than having them make their changes on a test/staging SH, pull the app from there onto the deployment server and push it out. Very similar to any other software development/production promotion approach.

[sowings]

I'd suggest a "sandbox" application that only lives on the search head where users can add their own knowledge objects, while still benefiting from the consistency provided by the DS.

[s2_splunk]

There are Splunk users that use a source control system as the source for deployment server and give their staff access to modify and check-in changes to knowledge objects under source control, which will subsequently be pushed out. Maybe that's another avenue you can investigate.

[s2_splunk]

You have to decided to manage SH configuration via deployment server, so your path is set for any app that is under DS management; you will have to modify/extend it at the source. As you noticed, deployment server will detect changes made to deployement apps and clients will pull those changes down and overwrite changes made locally. That is really one of the key concepts why DS exists.

There is no reason why you cannot have a separate public community app that is not managed by DS, where users on the same search head can create and share knowledge objects to address this use case.

[sloshburch]

I had considered that - removing write permissions - but I was thinking it would also mean that users can't create and share knowledge objects without adding them to the deployment server. Is that right or am I making an incorrect assumption here?