Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Homebrew 1.0.0 fallout #483

Merged
merged 9 commits into from Sep 27, 2016
Merged

Conversation

@aneeshusa
Copy link
Member

aneeshusa commented Sep 22, 2016

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.


This change is Reviewable

@aneeshusa aneeshusa changed the title Add homebrew_analytics module for robust disabling [WIP] Add homebrew_analytics module for robust disabling Sep 22, 2016
@aneeshusa aneeshusa force-pushed the aneeshusa:add-homebrew-state branch 2 times, most recently from a8cc11f to 5e8dfb5 Sep 23, 2016
@aneeshusa
Copy link
Member Author

aneeshusa commented Sep 23, 2016

Please check my reasoning on the second commit carefully when reviewing.

@aneeshusa aneeshusa force-pushed the aneeshusa:add-homebrew-state branch 4 times, most recently from 0c41d48 to 0406bf6 Sep 23, 2016
@aneeshusa
Copy link
Member Author

aneeshusa commented Sep 23, 2016

I also need to update the wiki to add brew analytics off to the list of instructions for setting up a new Mac builder.

@aneeshusa aneeshusa force-pushed the aneeshusa:add-homebrew-state branch from 0406bf6 to d91260d Sep 23, 2016
@aneeshusa
Copy link
Member Author

aneeshusa commented Sep 23, 2016

Closing/reopening to retry.

@bors-servo
Copy link
Contributor

bors-servo commented Sep 23, 2016

The latest upstream changes (presumably #486) made this pull request unmergeable. Please resolve the merge conflicts.

@aneeshusa aneeshusa force-pushed the aneeshusa:add-homebrew-state branch from d91260d to 7a1d3ab Sep 23, 2016
@Manishearth
Copy link
Member

Manishearth commented Sep 23, 2016

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)

@aneeshusa
Copy link
Member Author

aneeshusa commented Sep 23, 2016

OK, it looks like brew install is hanging when installing git. I heard that this now requires XCode 8, so let me try bumping that on Travis.

@aneeshusa aneeshusa force-pushed the aneeshusa:add-homebrew-state branch from 2de1bd5 to 49e8026 Sep 23, 2016
@aneeshusa aneeshusa changed the title [WIP] Add homebrew_analytics module for robust disabling [WIP] Fix Homebrew 1.0.0 fallout Sep 23, 2016
@aneeshusa aneeshusa force-pushed the aneeshusa:add-homebrew-state branch from 49e8026 to 1e57c8a Sep 23, 2016
@aneeshusa aneeshusa force-pushed the aneeshusa:add-homebrew-state branch 4 times, most recently from 7194fa0 to 918ec3c Sep 23, 2016
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.)
@aneeshusa aneeshusa force-pushed the aneeshusa:add-homebrew-state branch from 9ad768b to 3f0944a Sep 26, 2016
@aneeshusa
Copy link
Member Author

aneeshusa commented Sep 26, 2016

Updated some of the commit messages to mention any manual migration changes needed. (See also #488.)

aneeshusa added 5 commits Sep 23, 2016
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.
@aneeshusa aneeshusa force-pushed the aneeshusa:add-homebrew-state branch from 3f0944a to 4c67e65 Sep 26, 2016
@edunham
Copy link
Contributor

edunham commented Sep 26, 2016

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.
Review status: all files reviewed at latest revision, all discussions resolved.


Comments from Reviewable

@larsbergstrom
Copy link
Contributor

larsbergstrom commented Sep 27, 2016

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?

@aneeshusa
Copy link
Member Author

aneeshusa commented Sep 27, 2016

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.

@larsbergstrom
Copy link
Contributor

larsbergstrom commented Sep 27, 2016

@bors-servo r=edunham, larsbergstrom

@bors-servo
Copy link
Contributor

bors-servo commented Sep 27, 2016

📌 Commit 4c67e65 has been approved by edunham,

@bors-servo
Copy link
Contributor

bors-servo commented Sep 27, 2016

Test exempted - status

@bors-servo bors-servo merged commit 4c67e65 into servo:master Sep 27, 2016
3 checks passed
3 checks passed
code-review/reviewable 15 files reviewed
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test exempted
Details
bors-servo added a commit that referenced this pull request Sep 27, 2016
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 -->
@larsbergstrom
Copy link
Contributor

larsbergstrom commented Sep 27, 2016

Current migration status:
Linux minions all updated fine, but the mac ones are all getting "The Salt Master has cached the public key for this node, this salt minion will wait for 10 seconds before attempting to re-authenticate", which seems to be fixed by doing salt-key -d {mac} on the master followed by a reboot. Once the macs are updated, I will try to update the master.

@larsbergstrom
Copy link
Contributor

larsbergstrom commented Sep 27, 2016

All of the macs respond to a test.ping find, but when attempting to highstate with test=True I get:

servo-mac2:
    Minion did not return. [No response]

The minion logs look like:

2016-09-27 15:46:59,144 [salt.minion      ][ERROR   ][328] Error while bringing up minion for multi-master. Is mast
er at servo-master0.servo.org responding?
2016-09-27 15:47:00,220 [salt.loader      ][ERROR   ][449] Exception raised when processing __virtual__ function fo
r mac_system. Module will not be loaded 'service.enable'
2016-09-27 15:47:00,220 [salt.loader      ][WARNING ][449] salt.loaded.int.module.mac_system.__virtual__() is wrong
ly returning `None`. It should either return `True`, `False` or a new name. If you're the developer of the module '
mac_system', please fix this.
2016-09-27 15:47:28,684 [salt.state       ][ERROR   ][449] An exception occurred in this state: Traceback (most recent call last):
  File "/usr/local/Cellar/saltstack/2016.3.3/libexec/lib/python2.7/site-packages/salt/state.py", line 1733, in call
    **cdata['kwargs'])
  File "/usr/local/Cellar/saltstack/2016.3.3/libexec/lib/python2.7/site-packages/salt/loader.py", line 1652, in wra
pper
    return f(*args, **kwargs)
  File "/usr/local/Cellar/saltstack/2016.3.3/libexec/lib/python2.7/site-packages/salt/states/user.py", line 457, in
 present
  File "/usr/local/Cellar/saltstack/2016.3.3/libexec/lib/python2.7/site-packages/salt/state.py", line 1733, in call
    **cdata['kwargs'])
  File "/usr/local/Cellar/saltstack/2016.3.3/libexec/lib/python2.7/site-packages/salt/loader.py", line 1652, in wrapper
    return f(*args, **kwargs)
  File "/usr/local/Cellar/saltstack/2016.3.3/libexec/lib/python2.7/site-packages/salt/states/user.py", line 457, in present
    win_description)
  File "/usr/local/Cellar/saltstack/2016.3.3/libexec/lib/python2.7/site-packages/salt/states/user.py", line 92, in _changes
    lshad = __salt__['shadow.info'](name)
  File "/usr/local/Cellar/saltstack/2016.3.3/libexec/lib/python2.7/site-packages/salt/modules/mac_shadow.py", line 160, in info
    'login_failed_count': get_login_failed_count(name),
  File "/usr/local/Cellar/saltstack/2016.3.3/libexec/lib/python2.7/site-packages/salt/modules/mac_shadow.py", line 255, in get_login_failed_count
    ret = _get_account_policy_data_value(name, 'failedLoginCount')
  File "/usr/local/Cellar/saltstack/2016.3.3/libexec/lib/python2.7/site-packages/salt/modules/mac_shadow.py", line 119, in _get_account_policy_data_value
    raise CommandExecutionError('Unknown error: {0}'.format(exc.strerror))
CommandExecutionError: Unknown error: Command Failed: dscl . -readpl /Users/servo accountPolicyData failedLoginCount
Return Code: 181
Output: No such plist path: failedLoginCount
Error: <dscl_cmd> DS Error: -14261 (eDSUnknownMatchType)


2016-09-27 15:48:15,500 [salt.loader      ][ERROR   ][1065] Exception raised when processing __virtual__ function for mac_system. Module will not be loaded 'service.enabled'
2016-09-27 15:48:15,501 [salt.loader      ][WARNING ][1065] salt.loaded.int.module.mac_system.__virtual__() is wrongly returning `None`. It should either return `True`, `False` or a new name. If you're the developer of the module 'mac_system', please fix this.
2016-09-27 15:48:16,284 [salt.state       ][ERROR   ][1065] The named service buildbot-slave is not available
2016-09-27 15:48:16,291 [salt.loaded.int.module.cmdmod][ERROR   ][1065] Command 'launchctl list buildbot-slave' failed with return code: 113
2016-09-27 15:48:16,292 [salt.loaded.int.module.cmdmod][ERROR   ][1065] stderr: Could not find service "buildbot-slave" in domain for system
2016-09-27 15:48:16,292 [salt.loaded.int.module.cmdmod][ERROR   ][1065] retcode: 113
2016-09-27 15:48:41,252 [salt.minion      ][ERROR   ][328] Error while bringing up minion for multi-master. Is master at servo-master0.servo.org responding?

@larsbergstrom
Copy link
Contributor

larsbergstrom commented Sep 27, 2016

Also, this is basically what I had to do manually:

Linux:

service salt-minion stop
curl https://repo.saltstack.com/apt/ubuntu/14.04/amd64/archive/2016.3.3/SALTSTACK-GPG-KEY.pub | sudo apt-key add -
printf 'deb http://repo.saltstack.com/apt/ubuntu/14.04/amd64/archive/2016.3.3 trusty main\n' | sudo tee /etc/apt/sources.list.d/saltstack.list >/dev/null
sudo apt-get -y update
sudo apt-get -y install salt-minion=2016.3.3+ds-1
service salt-minion start

Macs:

chown -R servo /usr/local

su - servo
brew update
brew unlink saltstack
brew install https://raw.githubusercontent.com/Homebrew/homebrew-core/9e3a66b6b7ca978bfea86897dcc3391c37f9f0ef/Formula/saltstack.rb
sudo reboot
@aneeshusa
Copy link
Member Author

aneeshusa commented Sep 27, 2016

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?

@larsbergstrom
Copy link
Contributor

larsbergstrom commented Sep 27, 2016

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:

root@servo-master1:~# salt-master --version
salt-master 2016.3.3 (Boron)
@aneeshusa
Copy link
Member Author

aneeshusa commented Sep 27, 2016

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.

@aneeshusa
Copy link
Member Author

aneeshusa commented Sep 28, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

5 participants
You can’t perform that action at this time.