This is a bit of a sanity check/what I don't know can still hurt me. I have a indexer cluster that has a couple large (>1GB) apps that need to be deployed also they are relatively static in their config changes. So I currently have those apps being deployed via a deployment server with the app set to not restart splunkd. This helps reduce bundle deployment and validation times. What risks/issues am I unaware of in running this setup? Besides the obvious peers may get restarted if that app ever gets changed to restart splunkd.
I think we have some terminology mixed up. Indexer clusters are managed by the Cluster Manager, not by a Deployment Server. If you send apps to indexers from a DS then what you have is not an indexer cluster.
If you have independent indexers managed by a DS then you are in good company. The risk is with an indexer outage (like when a peer restarts). Any search that runs while the indexer is down will get incomplete results. A cluster, however, prevents that by having the data replicated on another indexer.
Meant to reply instead of posting a new comment.
Nope, my terminology isn't mixed up. I'm running both a cluster master to deploy apps from the master-apps directory to the peers and a deployment server to deploy a couple of large apps directly to the apps directory.
I'd like to add a consideration to the @richgalloway answer: why do you want to do this that surely doesn't run at the first restart (and restarting is mandatory in app installation)?
It'r definitively easier to manage your Indexers using a Master Node (It was created with this role!).
If yor need is to reduce bundle, probably the problem are the lookups, so you could blacklist some (or all) of them reducing the bundle dimension, solving the problem and maintaining the correct architecture.
Interesting. You don't have much company there.
There is risk involved if both the CM and DS push the same app. Bad things can happen if an app is installed twice on the same instance.