Will deployer delete an app locally created on SHC?

[att35]

We have a 4 node SHC connected to a deployer. 

For a usecase, I created a simple custom app that is just putting handful of dashboards together. Due to ease of use, I create this directly on SHC and all knowledge objects replicated among the members.

During the next bundle push, will deployer delete this app from SHC as it has no knowledge of it? Should I move this app under shcluster/apps folder on the Deployer as well to be safe?

Thanks,

~Abhi 

[kiran_panchavat]

@att35If you find the provided solution satisfactory, please proceed with accepting it.

[livehybrid]

Hi @att35 

No - Apps you create directly on the SHC will not be affected by deployment pushes from a SH deployer. 

The effect of changing deployer_push_mode only applies to apps pushed by the deployer, not apps created locally on the SHC. Although this doesnt mean that you should manage apps independently of the deployer 🙂 

Please let me know how you get on and consider accepting this answer or adding karma this answer if it has helped.
Regards

Will

[isoutamo]

Basically this is true, but how you can create (officially supported way) those apps locally on SHC nodes? You cannot do it on CLI and GUI there isn't option for creating app in any SHC member!

When you are creating a new SHC, you must use empty nodes which cannot contains old apps from SH.  If you need to migrate old SH into SHC then you must replicate those apps and other data via deployer.

This means that you must create an empty app (just base structure like app_xx/bin, app_xx/default, app_xx/metadata, app_xx/lookups) on deployer and then push it into your SHC members. After you have done it this way, you can add other KOs like dashboards, reports, alerts etc. via GUI on any SHC members and those are replicated correctly between nodes. 

What will happen those files in SHC member app_xx/local folder (and default) is depending on your push settings like @kiran_panchavat already told.

One notice your SHC size. It should always have odd number of members. RAFT protocol which are keeping your SHC up and running with correct captain needs this. Otherwise there are big possibility that it cannot elect a new captain after something has happened to old captain!

[kiran_panchavat]

@att35 This was an expected behavior with the default configurations. To overcome this you have to modify the configurations referring to the below document:

https://docs.splunk.com/Documentation/Splunk/9.3.1/DistSearch/PropagateSHCconfigurationchanges#Choos...

[kiran_panchavat]

@att35 

Yes, you need to adjust the deployer_push_mode to one of the other parameters, based on your requirements.

In general, there are four modes of deployer_push_mode:

- full

- merge_to_default

- local_only

- default_only

By default merge_to_default setting is enabled due to you are observing the behavior that you have mentioned.

- If set to "full": Bundles all of the app's contents located in default/, local/, users/<app>/, and other app subdirs. It then pushes the bundle to the members. When applying the bundle on a member, the non-local and non-user configurations from the deployer's app folder are copied to the member's app folder, overwriting existing contents. Local and user configurations are merged with the corresponding folders on the member, such that member configuration takes precedence. This option should not be used for built-in apps, as overwriting the member's built-in apps can result in adverse behavior.

- If set to "merge_to_default": Merges the local and default folders into the default folder and pushes the merged app to the members. When applying the bundle on a member, the default configuration on the member is overwritten. User configurations are copied and merged with the user folder on the member, such that the existing configuration on the member takes precedence.

- * If set to "local_only": This option bundles the app's local directory (and its metadata) and pushes it to the cluster. When applying the bundle to a member, the local configuration from the deployer is merged with the local configuration on the member, such that the member's existing configuration takes precedence. Use this option to push the local configuration of built-in apps, such as search. If used to push an app that relies on non-local content (such as default/ or bin/), these contents must already exist on the member.

- If set to "local_only": This option bundles the app's local directory (and its metadata) and pushes it to the cluster. When applying the bundle to a member, the local configuration from the deployer is merged with the local configuration on the member, such that the member's existing configuration takes precedence. Use this option to push the local configuration of built-in apps, such as search. If used to push an app that relies on non-local content (such as default/ or bin/), these contents must already exist on the member.

Based on your requirement you can change the deployer_push_mode.

It is highly advisable to review the document below to gain a clear understanding of the behavior before implementing any changes.

https://docs.splunk.com/Documentation/Splunk/9.3.1/DistSearch/PropagateSHCconfigurationchanges#Choos...