Remove Old Root-Installed Gems#66922
Conversation
Follow-up to #50661, which added a temporary Chef resource to remove the unused `/etc/gemrc` file from all of our persistent managed servers. It's been just over two full years since it was first merged, so I'm pretty sure it should be safe to remove by now.
snickell
left a comment
There was a problem hiding this comment.
Looks good, and agree the DTT should flag if there's something we missed.
| # For simplicity, just check for one arbitrary gem. It's a fragile | ||
| # strategy, but this code is intended to be temporary and a false negative | ||
| # is harmless. | ||
| canary = '3.1.0/gems/rails-6.1.7.7' |
There was a problem hiding this comment.
I'm confused to see the rails used as the canary gem since it doesn't appear in the list of gems that would be uninstalled in the PR description, but I might have misunderstood something.
There was a problem hiding this comment.
I could probably have been more clear with what I meant with that list.
Right now when you spin up a fresh adhoc, it installs all of our Gemfile dependencies including Rails to ~/adhoc/vendor. But the base AMI we use comes with I think 92 gems already installed to /usr/local/lib. Most of those gems remain installed even after running gem uninstall --all, but the ones listed above get removed.
There was a problem hiding this comment.
What this means for our persistent managed servers is that this PR will bring them more in line with what we would get if we were to recreate them from scratch, by removing all of the Gemfile dependencies those servers still have installed to /usr/local/lib despite no longer using. But we will still end up having some drift from the "clean server" state, in that we remove a few more gems than we strictly need to.
There was a problem hiding this comment.
Or, more succinctly:
| environment | ll /usr/local/lib/ruby/gems/3.1.0/gems/ | wc -l |
|---|---|
current staging |
612 |
| fresh server | 92 |
| state after this PR | 85 |
sureshc
left a comment
There was a problem hiding this comment.
I'm taking a break from vacation to do my on call shift tomorrow (Friday). If you want to try releasing this tomorrow, I'm available to help shepherd it through.
Planned follow-up to #66536, which switched us from installing gems as the root user to doing so as the ubuntu user with the
deploymentoption.That change has been successfully applied to all of our persistent managed servers (after a couple of attempts), and we are now successfully using the new
deployment-installed gems on all persistent managed servers. Now, we want to minimize drift by removing all of the gems that were previously installed by root.This temporary chef resource should handle that.
Testing story
Verified on an adhoc; spun one up based on staging latest (which is currently installing all gems in
deploymentmode) and manually installed all gems in our currentGemfile.lockwithsudo, to emulate the current state of our build pipeline servers.Finally, I merged this change in, let it build, and manually executed it with
sudo chef-client -o cdo-apps. I verified that the web application servers can be built and initialized correctly afterwards, but I will largely be relying on the DTT and our other CD operations to verify that we haven't broken any obscure functionality.Note
One thing to note is that we do end up with fewer gems installed after running this recipe than we do on a clean server (before, after).
Specifically, this recipe will remove the following gems from
/usr/local/lib/ruby/gems/3.1.0/gems/on an adhoc:I'm calling this out because it is technically an example of drift between our persistent managed servers and what we'd get if we recreated them from scratch, but as far as I can tell it does not impact any actual functionality. We should be entirely depending on the gems installed to
~/adhoc/vendor/bundle/ruby/gems/3.1.0/gems/rather than any system-level gems.Follow-up work
Once this resource has executed on all persistent managed servers, we can remove it.