master should not use two top level directories in /srv

[karlp]

Currently, by default, salt uses/expects two top level directories in /srv, /srv/salt and /srv/pillar. While the two directories are logically separate, and pillar's can contain sensitive data and so on, large portions of the documents refer to and recommend using pillar data for templating states. This makes it very appealing to have both the /srv/salt directory and the /srv/pillar directory under version control. To this end, and to limit clutter in the system "shared" /srv top level directory, I propose that the pillar and salt directories move down a level by default. Something like /srv/salt/states and /srv/salt/pillar.

I'm well aware that this is not something that would be easy to migrate from old installations. I'm also well aware that I can configure this myself in the salt master config. However, I feel that the default setup should only use a single top level directory.

[thatch45]

I completely agree, this was a mistake, I want to change it, but the question is, how can we do it without breaking everything for everyone? Really, I need some ideas as to how we can do this in a smooth way

[karlp]

one way... (there's others)

have the packages create a new directory /srv/saltstack. Then, if the package installer finds anything in the /srv/pillar or /srv/salt directories, it creates symlinks and writes a MIGRATION-README file?

Or, just outright say, "this is still growing software, this release is not backwards compatible in defaults, here's how to migrate"

Or, in the package installers, if it finds the old directories, it modifies the config it's installing to use those directories? (downside here is old users never get the new paths unless they do it themselves)

[thatch45]

Yes, I really dislike 2, packages should not dynamically change configs, this never works and packagers will not go for it, and the first is getting close.
I think that it would be good enough if just new installs changed the structure, in this case we just ask packagers to lay down a default config with the directory changes. Even then though this will silently break unchanged configs.

[EvaSDK]

Unless I misunderstood the problem, both directories are configurable via master configuration file, if someone wants them under the same directory like say /srv/salt/{states,pillars}, it is already very easy to do.

If changing the default config is the only thing there is to do, just do it, admins and packagers will know how to handle it, but don't try to do anything automagic like moving files via salt-master itself.

[UtahDave]

This isn't going to happen at this point.