Can one deployment client receive apps from multiple repositoryLocation(s)?

[chris94089]

Greetings,

In https://docs.splunk.com/Documentation/Splunk/8.0.6/Admin/Serverclassconf , the description for serverclass.conf, it details this:

[global]
repositoryLocation = <path>
* The repository of applications on the server machine.
* Can be overridden at the serverClass level.

 It then goes on to describe the serverclass level:

[serverClass:<serverClassName>]
* A server class can override all inheritable properties in the [global] stanza.
repositoryLocation = <path>

Taking these together, it seems a Deployment Client can only ever receive its apps from one  repositoryLocation at a time.  Is this correct?

If so, bummer.  If not, is there a way to set up a Deployment Server to have two repos, say one for inputs, the other for outputs, and have the Client configured like so:

[deployment-client]      
clientName = apps_from_output_repo.apps_from_inputs_repo

In my head each repo would be its own app in the Deployment Server, and each have its own serverclass.conf, but one app would handle the [global] level, the other the [serverClass] level.

[chris94089]

The use case is a niche.  Using kubernetes, I grafted a git-sync sidecar to our Splunk container.  The repo shows up in $SPLUNK_HOME/etc/apps  as a "deployment server app".  Our users are programmers themselves, so somebody had the idea of using two repos and allowing our users access to one of them to set up their own inputs.  We would manage the outputs repo since the outputs have certificate information.  

The idea is a Deployment Server instance with two custom apps that each contain their own serverclass.conf and repositoryLocation.  By giving our programmers ownership over their inputs, we as a team might have less  things to manage.

My question hovers around whether or not this use case is supported, not how to design apps, or server classes, goodness knows there's already enough documentation on that topic.

If it's not supported, it seems the only way to provide this kind of service would be to write up a middle program that moves the apps from both sources into a single, flat, directory.  

[richgalloway]

It's common, even recommended, to put input and output configurations in separate apps.  Those apps, however, would both reside in the same repository - usually $SPLUNK_HOME/etc/deployment-apps.  What is the advantage of separate configurations both by app *and* repository?