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

Bug 1603193 - Provisioning bustage fixes. a=bustage #261

Merged
merged 2 commits into from
Dec 14, 2019

Conversation

asutherland
Copy link
Contributor

I forgot to mark the scripts executable. Whoops!
Also, a ride-along fix here to make sure that any work we had in progress in index-scratch gets moved to the actual permanent EBS store.

Currently if we abort indexing, any work that was on /mnt/index-scratch
partition will be lost because instance storage is lost when the machine
shuts down.  (And indexing failures immediately terminate the indexer as
part of `send-failure-email.py`.)
@asutherland asutherland merged commit 19da4a0 into mozsearch:master Dec 14, 2019
@asutherland asutherland deleted the provision-fixes branch December 14, 2019 22:20
@asutherland
Copy link
Contributor Author

The ride-along index-scratch stuff worked. On my dev branch I broke the indexer and I happily got: /index/interrupted/config.json /index/interrupted/gecko-blame.tar /index/interrupted/gecko-dev.tar /index/interrupted/git_hg.map /index/interrupted/mozilla-central

Disclaimer: I had to do: lsblk to identify the exactly 300G partition and then sudo mount that. I have it on my mental to-do list to update the docs for debugging indexers, but I'm think it might be best if we can just add a startup script or something that understands how to re-attach the /index mount-point as long as the volume is still attached to the indexer. (As opposed to it having been in the process of being moved to the web-server.)

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