Cleanup out-of-sync copies of ref images

RESOLVED FIXED

Status

mozilla.org Graveyard
Server Operations
RESOLVED FIXED
9 years ago
3 years ago

People

(Reporter: joduinn, Assigned: phong)

Tracking

Details

While setting up new slaves this week, we hit problems where some of the slaves were slightly different to what we expected. 

1) At least one of the refimages used this week has production (not staging) ssh keys on it. We're not sure how this happened, but this needs to be fixed, as a new unverified slave should not be able to access production systems. (Also, this caused last night's testing to fail out in staging, because of mismatched keys.)

2) There have been a series of recent changes to ref images for puppet/opsi. Not all of these showed up as expected. Its unclear which ref images have which of these changes.


From talking with Phong, it seems there are different copies of the refimages being used for cloning. Phong, correct me if I missed anything, but as best as I can remember, you said there are:

2 x xp talos ref image
2 x vista talos ref image
2 x 10.4 talos ref image
2 x 10.5 talos ref image
2 x 10.5 build/unittest mini ref image
1 x 10.5 build/unittest xserve ref image
1 x linux talos ref image


Phong: 

1) for the refimages where there are multiple copies, can you diff to see which ones have out-of-sync versions? If they are identical copies can you bring one online? If you find any diff can you bring *both* online, so we can login to both machines, figure out whats going on, and try to detangle the differences?

2) for any refimages where there is only one copy, can you bring it online, so we can verify what keys are installed?

Updated

9 years ago
Assignee: server-ops → phong
(Assignee)

Comment 1

9 years ago
created all new ref image to match MTP and MV images.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.