Affects Version/s: None
Fix Version/s: None
There are some config files (webrouting config is a good example) that are very important to have around during development, but that don't necessarily make much sense to expose to users (or at least, to encourage users to consider modifying them).
We should establish some kind of common pattern for how to maintain these config files without exposing them to the user as directly as we do with the "normal" config files. This could be by putting them in a secondary config directory, embedding them in the jar, etc. (I believe that PuppetDB already has at least a partial solution / strategy for this, would be good to update this ticket with the details.)
We probably need to have a bit of disussion around what the solution should look like, but it will probably end up being something along the lines of:
- Make sure we support multiple paths being passed in for the `--config` arg to TK (pretty sure we already do)
- Make sure it's possible for those paths to be relative
- Make sure that for relative paths, the system includes the classpath in the search path so that we can put config files into the jars?
- Add something to the default init scripts (where we launch java) that includes a secondary path (non-user-facing) for config files (look and see what PuppetDB is doing for this, because I'm pretty sure they're already doing it)
- Move the web-routing config files to that secondary path
It's probably also worth discussing whether we actually want to put the non-user-facing config files into the jars, or just into a secondary directory (I think PuppetDB is doing the latter). It might be kind of magical if they're in the jar; we should probably at the very least make sure we're logging some info about which config files are being loaded from jars if we do go down that path.