Deployment Architecture

Deployment Server - local folder not being pushed to Search Head cluster

jwalzerpitt
Motivator

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?

Thx

0 Karma

koshyk
Super Champion

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

realsplunk
Builder

This is good to avoid breaking local SH folder 🙂

0 Karma

ddrillic
Ultra Champion

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 $SPLUNK_HOME/etc/apps/TA_Syncsort_Ironstream_Data_Model_for_Mainframe/default

0 Karma

koshyk
Super Champion

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

ddrillic
Ultra Champion

Ok, isn't the intention that the packaged app would be exclusively in default and on-going changes in local? The challenge would be to back it up, right?

0 Karma

koshyk
Super Champion

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

0 Karma
.conf21 CFS Extended through 5/20!

Don't miss your chance
to share your Splunk
wisdom in-person or
virtually at .conf21!

Call for Speakers has
been extended through
Thursday, 5/20!