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 upFix Homebrew 1.0.0 fallout #483
Conversation
a8cc11f
to
5e8dfb5
|
Please check my reasoning on the second commit carefully when reviewing. |
0c41d48
to
0406bf6
|
I also need to update the wiki to add |
|
Closing/reopening to retry. |
|
|
|
Reasoning looks fine. I don't exactly understand what the first commit is about, but comparing with the original code it seems okay too, r=me if that suffices. (once travis passes) |
|
OK, it looks like |
7194fa0
to
918ec3c
For some reason it seems Salt is not invalidating the `_modules` cache, causing build failures on upgrade builds (i.e. the second build on a not-from-scratch run). Invalidate the cache manually. Note that `nullglob` is set for safety, but we always expect `rm` to find cache files to invalidate. In case it does not find any files, the glob will expand to nothing, which is considered an error, causing failure via `errexit`. That is, not ignoring the result of rm is intentional. (`nullglob` is nicer than `failglob` because it is friendlier to loops over globs.)
|
Updated some of the commit messages to mention any manual migration changes needed. (See also #488.) |
Homebrew recently changed their packaging of Salt and Python, using a virtualenvs for Salt. Because we were pinning an old version of Salt, but not the rest of Homebrew, this caused problems where pip was not being resolved properly. Update Salt to the latest version to fix this. As part of the update, also update some states to avoid deprecated parameters in favor of newer ones: - archive.extracted: archive_user -> user, group - cmd.run: user, group -> runas Note that due to saltstack/salt#36552, `archive.extracted` states still have the archive_user argument to ensure parent directories are made with the correct permissions. saltfs-migration: Upgrade Salt on all machines. Steps: - Stop all salt-master and salt-minion services. Because we're upgrading Salt by two major versions at once, there are no guarantees that the masters and minions with different versions will be able to communicate. - Use the install script to re-install Salt on each machine, the master first then the minion. - Restart the salt-master and salt-minion services; pay attention to the system logs in case of startup failure. - Do NOT run a highstate until all minions and masters have been updated to Salt 2016.3.0.
The install_salt script may be called again to reinstall or update Salt. Because we are Salting our configuration files, force apt-get to use any existing configuration files and ignore updates in the Salt packages.
OpenSSL is a "keg-only crate", which Homebrew 1.0.0 won't link because ``` we may end up linking against the insecure, deprecated system OpenSSL while using the headers from Homebrew's openssl. ``` Instead, use the `OPENSSL_INCLUDE_DIR` and `OPENSSL_LIB_DIR` to explicitly pass the paths to the Homebrew OpenSSL. Note that these paths are currently hardcoded because they are unlikely to change. For some reason, Homebrew was reporting this error on its stderr but Salt was not picking it up as and failing the state - possibly because the exit status seems to have been 0. saltfs-migration: Run `brew unlink --dry-run openssl` on the Mac builders, then `brew unlink openssl` once confirming the output is as expected. This will unlink openssl on the existing builders.
If a different version of Salt is already installed via Homebrew, it will not allow installing a different version without previously unlinking the old one. Ideally there would be an atomic operation to do both of these in one command, but it appears Homebrew does not have one. Thus, users of this script should be careful to watch the output in case the script is interrupted and no Salt installation is left linked.
Use an idempotent cmd.run to tap `homebrew/versions` only if necessary. Homebrew 1.0.0 apparently tightened its return codes and will exit with a non-zero status if linking fails during installation; there is no way to install without linking or install and link --overwrite in one operation. This makes it difficult to install multiple versions that have conflicting links from the CLI, so add a custom script to handle ensuring that autoconf and autoconf213 are installed and linked properly, with autoconf's links over autoconf213's links, in an idempotent way and doing as little as possible.
|
Reviewed 9 of 9 files at r10, 1 of 1 files at r11, 6 of 6 files at r12, 1 of 1 files at r13, 2 of 2 files at r14, 1 of 1 files at r15, 2 of 2 files at r16. Comments from Reviewable |
|
OK, I think that both @edunham and I are good with this. Thanks for all the heavy lifting on this PR! Is it ready to merge and try out? Also, I'm assuming I will need to pretty much atomically roll this upgrade out to all of the machines to get them on the updated salt versions, right? Do the master first, then all the clients? |
|
Yeah, this should be good to merge and try out; don't forget the migration steps. Because we're jumping two major versions, I doubt they will interoperate (as opposed to just one version), so I think an atomic update is best: stop all services, run the upgrade via the install script (instead of raw apt-get or homebrew), restart the master then restart the minions. |
|
@bors-servo r=edunham, larsbergstrom |
|
|
|
|
Fix Homebrew 1.0.0 fallout Homebrew 1.0.0 has just been released with some breaking changes. To handle all of them, this PR has a lot of changes, here are the main points: - Add a new `homebrew` execution module and `hombrew_analytics` state module to fix analytics disabling - Fix `autoconf`/`autoconf213` installing and linking - Use env vars to specify OpenSSL location because linking fails (fixes #479) - Upgrade to XCode 8/OS X 10.11 on Travis (fixes #382) to fix installing git - Update Salt, leaping two major versions ahead to 2016.3.3 (the latest), due to changes in Homebrew Python/Salt packaging not available in our pinned old Salt - Make our install and dispatch scripts more robust: - Force apt-get to use existing configuration files and ignore updates in Salt packages during installation - Unlink Salt if we have installed it via Homebrew previously before installing a new one - Allow failures when building old revs when checking upgrades (upstreams change) - Manually invalidate the Salt cache between runs See commit messages for full details. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/saltfs/483) <!-- Reviewable:end -->
|
Current migration status: |
|
All of the macs respond to a servo-mac2:
Minion did not return. [No response]The minion logs look like:
|
|
Also, this is basically what I had to do manually: Linux:
Macs:
|
|
I don't think running the old master + new minions will work, you'll probably need to update + restart everything. Did the install script not work for some reason? |
|
Which scripts? I did the install per the comment about migration steps in: 87d9741 ? I also did the master manually on servo-master1. It appears to be the correct version:
|
|
Sorry, I should have included the link: https://github.com/servo/saltfs/blob/master/.travis/install_salt.sh is the install script (which we use on Travis/in Vagrant), and should also handle upgrades as of this PR. Taking a look at the highstate failures now. |
|
Not sure what the budget looks like, but we could consider spinning up a secondary cluster temporarily to work out the kinks next time we have a big change before changing our production machines. |
aneeshusa commentedSep 22, 2016
•
edited
Homebrew 1.0.0 has just been released with some breaking changes. To handle all of them, this PR has a lot of changes, here are the main points:
homebrewexecution module andhombrew_analyticsstate module to fix analytics disablingautoconf/autoconf213installing and linkingSee commit messages for full details.
This change is