Use Salt gitfs to keep master synced with repo

[aneeshusa]

Docs: https://docs.saltstack.com/en/2015.5/topics/tutorials/gitfs.html

Salt has a built-in backend that uses a git repo (such as this one) to provide the files in the /srv/salt tree (the fileserver).

We should use it instead of manually git pulling on the master.

[metajack]

+1

Is this feature new? I don't remember seeing this back when we set this up.

[aneeshusa]

This has been around for a long time, although I'm not sure exactly when it was added (at least as old as 2014.7.0, possibly as old as 0.16.3 based on a quick skim of the docs).

I'm not yet sure about how this would interact with the workflow of iterating on changes directly on the servo-master machine.

[larsbergstrom]

If we don't have a local filesystem we can edit, what's the procedure for doing test highstate against the live system? There are a few pieces (e.g., the web hooks, buildbot, etc.) that we have no testing for and, in practice, I've needed to do and roll out 3 or 4 fixup tries before I actually get the original patch that was r+'d live.

cc @edunham

[aneeshusa]

We can pass a command line flag to the salt command to point to a different configuration directory, which lets us set up test configurations that point at local files to use interactively. This way, regular salt commands continue to use the gitfs fileserver backend, and we can set up separate temporary directories for testing. I'd recommend putting such directories in /tmp so they don't stick around too long.

That being said, testing in production makes me uneasy and I'd prefer to build a better testing story for our configurations, both making testing inside Vagrant easier and adding more automated functional tests. It's just too easy to forget to pass a command line flag to Salt (I've done this more times on my own setup than I'd like to admit).

[aneeshusa]

Hit the wrong button, whoops.

[aneeshusa]

FYI, I've been looking into this for #350. The solution I mentioned above (custom config directories) won't work, but I've found an alternative solution. See #350 for the details.