Closed
Bug 632103
Opened 14 years ago
Closed 14 years ago
remove DO_NOT_START check from runslave.py
Categories
(Release Engineering :: General, defect)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: dustin, Assigned: dustin)
References
Details
Attachments
(1 file)
1.30 KB,
patch
|
bhearsum
:
review+
dustin
:
checked-in+
|
Details | Diff | Splinter Review |
Since we have a UI to disable slaves, there's no need to add an extra slave-side file to get that effect.
Comment 2•14 years ago
|
||
What's the supported way to disable a slave if the allocator is down? Just move the tac file out of the way?
Assignee | ||
Comment 3•14 years ago
|
||
Yes.
If the slave allocator is down, we should be hard at work getting it back up, anyway, and probably disabling slaves is the least of our worries during that time. Also, any previously-disabled slaves will stay disabled if the allocator is down.
Comment 4•14 years ago
|
||
Comment on attachment 510348 [details] [diff] [review]
m632103-puppet-manifests-r1.patch
I think there's still a need to be able to disable slaves when the allocator is down, but creating this file is just as easy as moving the tac out the way, r+.
Attachment #510348 -
Flags: review?(bhearsum) → review+
Assignee | ||
Comment 5•14 years ago
|
||
Comment on attachment 510348 [details] [diff] [review]
m632103-puppet-manifests-r1.patch
1099e90f1e1f
Deployed, and I've seen a slave start up on each of the masters, so I think we're good.
Attachment #510348 -
Flags: checked-in+
Assignee | ||
Updated•14 years ago
|
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•