Closed Bug 1062465 (foopy64) Opened 10 years ago Closed 10 years ago

foopy64 problem tracking

Categories

(Infrastructure & Operations Graveyard :: CIDuty, task)

ARM
Android
task
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: RyanVM, Unassigned)

References

Details

The pandas connected to it are finding all kinds of fun ways to break while running tests. Callek suspects it's a foopy issue. Disabling the slaves attached to it for now.
coop/amy/kim,

Is this foopy one of the ones we decided to keep in production? if so can we identify one to swap it with? If not I'll get a decom bug ready.
Summary: foopy64 is very sick → foopy64 problem tracking
Coop, is this the one you disabled last week?

It is not one scheduled for decom, no. And it shouldn't be decommed, it still has years of warranty life.
No, the one I disabled and subsequently re-enabled was foopy39.

I would advocate rebooting foopy64, running diagnostics, and then re-enabling it if it passes or repairing it if necessary.
Alias: foopy64
Depends on: 1066765
Re-enabled all attached pandas. Back in service.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
No longer blocks: panda-0395
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I've created the device dirs and re-enabled the associated pandas in slavealloc. It's now running jobs.
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Re-opened for disk replacement.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Created device dirs, and returned to production.
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Product: Release Engineering → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.