On my Deployment server in the /opt/splunk/etc/deployment-apps directory, I have the Splunk_TA_f5-bigip app with a local directory that contains a transforms.conf file. I reloaded the deploy server and then went to my Search Head cluster deployment server and verified that the transforms.conf file exists in /opt/splunk/etc/shcluster/apps/Splunk_TA_f5-bigip/local/ directory (and verified the contents of the file).
I then applied the shcluster bundle to my three search heads and waited a few minutes before checking to see if the local folder and the transforms.conf file made it over, and it did not. Running ls shows no local folder under the Splunk_TA_f5-bigip directory on either of the three search heads.
Am I missing a step to get the local folder with the transforms.conf file over from the Deployment server to the search head deploy serves and then finally to the three search head servers?
Welcome to the "Nightmare" of SH clustering. Anything "local" in your Deployer(shcluster) will be merged to "default" in the SH members !!
So the purity of code is lost which we have suffered for quite long. We have asked Splunk multiple times to avoid this, but ... The reason for Splunk NOT to do this is, when you do a change within the SH member UI, that's what comes to "local" of the SH member.
The only way we do is, to manually copy the code from SH member to git repository on a monthly basis and delete from SH local.
Please read this thread and my update on how to workaround things
Interesting @koshyk - looking on the deployer at
$SPLUNK_HOME/etc/shcluster/apps/TA_Syncsort_Ironstream_Data_Model_for_Mainframe/default and on the SH I see most of it under
yes, the flow is
Deployer (shcluster/apps/<app name>/default/) => SHmember (etc/apps/<app name>/default/) Deployer (shcluster/apps/<app name>/local/) => SHmember (etc/apps/<app name>/default/)
So ultimately, the changes in BOTH default & local of the deployer is merged into "default" of SH member. So we cannot distinguish which one is which .. and is a nightmare for orchestration/automation systems
agreed on the intention.
But from a "code purity" , it is not good for the application to alter the code which is being deployed as it makes automation very hard
For example, say you modified an app within "local" and you have checksum or orchestration systems to verify if someone have modified the code and it will always be highlighted. Also it is a nightmare to restore copy from backup/git