Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upSalt the Salt master #350
Salt the Salt master #350
Conversation
|
OK, this is ready for review. See the commit messages for details; also, a few notes:
|
|
Rebased since #298 landed. |
|
|
|
Reviewed 1 of 11 files at r6, 4 of 4 files at r7, 3 of 3 files at r8, 3 of 3 files at r9. _modules/launchctl.py, line 3 [r9] (raw file):
It looks like we're vendoring this in from the Salt builtin module (https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.launchctl.html). Do we need to worry about keeping this up to date with changes that Salt makes upstream, or will it be obsoleted relatively soon once we upgrade our Salt version? Comments from Reviewable |
|
@edunham I backported that module temporarily; we shouldn't need to update it unless it breaks, and we can simply remove it once we've updated Salt. I rebased the branch and made some tweaks, but haven't tested them in Vagrant yet because my home Internet connection is slower than at school. Do you know why Travis doesn't seem to be triggering? |
|
Not sure what's up with Travis; I've manually restarted https://travis-ci.org/servo/saltfs/builds/128187498 . Edit: Lars had some GitHub integration issues, https://twitter.com/larsberg_/status/743857405319077888, around the time that Travis failed to notice this PR. Possibly related. |
be72774
to
770cf2f
|
Rebased, but I want to tweak this a little more before merging. |
770cf2f
to
afba644
|
Rebased with tweaks and lightly tested in Vagrant. Ready for review. |
|
|
Use Salt to install the Salt master. The Salt master will not get restarted automatically, neither on configuration changes nor on package changes. Instead, it will need to be manually restarted to avoid interrupting the in-progress highstate as well as allow for proper update ordering. (Salt masters must be updated before Salt minions.) Use Jinja to generate the config file YAML directly, preventing typos in the master config file and providing access to master configuration options in the SLS file (e.g. the file_roots locations).
Previously, the minion config was used to specify that a local set of file trees should be used. However, in order to test that the Salt master states function, and to more closely match the actual deployment of our minions, amend the minion config to point to a localhost master. Additionally, amend our Travis config and Vagrantfile to explicitly pass options to set the local file and pillar trees. Only sync them via Vagrant shared folders for the Salt master, which should have them available to allow debugging. Because using Salt is the only way to learn which minions (ids) would have a Salt master running on them, hardcode the salt-master\d+ regex into the Vagrantfile. In the future, this will allow adding a smoke test that check if the master can test.ping a local minion (on the same VM). However, this requires the minion to be started, which requires that the Salt minion also be salted, (which requires this PR to backport the launchctl.py execution module).
Use gitfs backed by the saltfs repo (https://github.com/servo/saltfs/) as the main source for the Salt file tree. For local testing, additionally configure a local directory in /tmp as a Salt file tree root, and give it precedence over the gitfs tree. This allows temporarily cloning the saltfs repo into that directory and makes local changes to iterate on them. Add an ADMIN_README file with some ground rules about proper usage of the directory; this file should be set as immutable, but Salt does not yet have a module/state for this.
|
Reviewed 3 of 4 files at r11, 4 of 4 files at r12, 3 of 3 files at r13. Comments from Reviewable |
|
@bors-servo r+ |
|
|
Salt the Salt master Use Salt to install the Salt master. The Salt master will get restart on configuration changes, but will need to be manually restarted on package changes to allow for proper ordering of updating. (Salt masters must be updated before Salt minions.) Use Jinja to generate the config file YAML directly, preventing typos in the master config file and providing access to master configuration options in the SLS file (e.g. the file_roots locations). Incorporates and thus fixes #298. TODO: - [x] Add gitfs support. Fixes #264. - [x] Add _modules/ dir and backport `launchctl.py` module TODO after landing: - [ ] Add master install instructions to the wiki - [ ] Update Salt-inside-Vagrant usage instructions on the wiki After I finish the WIP tasks, landing this will unblock a bunch of other things that need the `launchctl.py` module (upgraded ssh, salt-minion salting, upgrading salt, etc.) <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/saltfs/350) <!-- Reviewable:end -->
|
|
|
I think I'll need to backport the |
037d31b
to
f1054aa
|
OK, I backported the pip execution and state modules. Something important I discovered is that custom modules with the same name don't work properly, so I prefixed the files with Should be good to go now. |
Also update the buildbot slave state to use the now-working service state on OS X, and update the name of the service from 'buildslave' to 'buildbot-slave' for better distinguishability. Add a note to README.md about licensing of files taken and/or modified from the main Salt repo.
The backported versions support old and new pips more robustly without depending on pip internals. Recently (in version 8.1.2), pip changed their internals in a non-backwards compatible way, breaking the Salt pip modules. Salt used to depend on these internals, but has since been updated to no longer depend on them as they have no compatibility guarantees. We have been encountering issues where Salt is finding a new pip version, even though the installed pip is old (6.1.1). To work around this issue, backport updated modules that handle both old and new pips.
f1054aa
to
a713928
|
It turns out the file naming wasn't the issue, and that giving the files the same name is the right thing to do for overriding. However, our version of Salt is so old that the backported pip modules weren't working properly (looking for Salt utilities that don't exist in our version), so I've backported only the needed changes to pip_state.py. Also, I added some headers to (try to) comply with the Apache 2.0 license of the backported modules. |
|
All of the test failures are happening on the builders where we test the PR as an upgrade; they fail when applying the initial highstate (of the old code). All of the builders that test the PR from scratch are passing, though, so I think this is OK. |
|
@edunham Is there anything else left to review here? We're having to do all manual merges to saltfs until this lands. |
|
Reviewed 2 of 2 files at r14, 1 of 1 files at r15. Comments from Reviewable |
|
I think that the problems we're encountering from outdated Salt version are greater than any problems likely to remain in this PR. The Travis failures look like the standard Salt version issues we've been seeing. |
|
Just a clarification, this PR doesn't update the whole Salt version, only backports a few modules. |
aneeshusa commentedApr 30, 2016
•
edited
Use Salt to install the Salt master.
The Salt master will get restart on configuration changes,
but will need to be manually restarted on package changes to
allow for proper ordering of updating.
(Salt masters must be updated before Salt minions.)
Use Jinja to generate the config file YAML directly, preventing
typos in the master config file and providing access to master
configuration options in the SLS file (e.g. the file_roots locations).
Incorporates and thus fixes #298.
TODO:
launchctl.pymoduleTODO after landing:
After I finish the WIP tasks, landing this will unblock a bunch of other things that need the
launchctl.pymodule (upgraded ssh, salt-minion salting, upgrading salt, etc.)This change is