Closed Bug 914805 Opened 7 years ago Closed 6 years ago

Integrate slaveapi into slave heath

Categories

(Release Engineering :: General, defect, P2)

x86
Linux
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: coop, Assigned: coop)

References

Details

(Whiteboard: [dashboard][slaveapi][capacity][slavehealth])

Wouldn't it be great to be able to reboot slaves directly from slave health? Yeah, it would.
Indeed! Slave Health should be able to post to http://slaveapi-dev1.srv.releng.scl3.mozilla.com:8080/slaves/<SLAVE>/actions/reboot to do this already. Once bug 929584 is fixed we can point it at production.
Assignee: nobody → coop
Priority: -- → P3
Whiteboard: [dashboard][slaveapi][capacity] → [dashboard][slaveapi][capacity][slavehealth]
Going to start poking at this today.

bhearsum: any reason not to use https://secure.pub.build.mozilla.org/slaveapi/ instead of the dev instance now?
Status: NEW → ASSIGNED
Priority: P3 → P2
(In reply to Chris Cooper [:coop] from comment #2)
> Going to start poking at this today.
> 
> bhearsum: any reason not to use
> https://secure.pub.build.mozilla.org/slaveapi/ instead of the dev instance
> now?

Nope! The production instance is the correct one to use.
Depends on: 952264
Removing blockers.

New code reads history for slaveapi rather than kittenherder files. We'll lose that data every time we restart slaveapi until bug 913601 is fixed, but the kittenherder data hadn't been updated in months anyway.

Enough of bug 952264 is deployed already to make the history and timing parts of the code work now.
No longer depends on: 913601, 952264
https://hg.mozilla.org/users/coop_mozilla.com/slave_health/rev/38e90b51cd41

I'm sure people will have issues with the notifications and timing, but we can fix those issues in follow-up bugs.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Component: Tools → General
You need to log in before you can comment on or make changes to this bug.