Closed
Bug 692804
Opened 13 years ago
Closed 9 years ago
we should be able to tell slavealloc to send a specific number of slaves of a given pool to a specifc master
Categories
(Release Engineering :: General, defect, P4)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: jhford, Unassigned)
Details
(Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2556] [slavealloc])
When doing a time-critical release, its really frustrating to see a bunch of jobs pending on 1 of 2 slaves. We should have a knob that says "I am doing a release and I want X of this type of slave without having to specify specific slaves to push around
Comment 1•13 years ago
|
||
IMHO the right way is to allow release jobs to happen in any master rather than lock them to a specific master where we really have a silo rather than the whole pool.
Comment 2•13 years ago
|
||
I think this is a great idea. Let's be sure to avoid calling turning this into "release mode" when we build it, though. Having the generic ability to say "gimme more slaves" could be useful elsewhere.
Reporter | ||
Updated•13 years ago
|
Summary: we should be able to tell slavealloc a master is doing a release and it should throw slaves at the master → we should be able to tell slavealloc to send a specific number of slaves of a given pool to a specifc master
Comment 3•13 years ago
|
||
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #1) > IMHO the right way is to allow release jobs to happen in any master rather > than lock them to a specific master where we really have a silo rather than > the whole pool. actually, I'd rather have masters that *only* did releases.
Reporter | ||
Comment 4•13 years ago
|
||
(In reply to Chris AtLee [:catlee] from comment #3) > (In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #1) > > IMHO the right way is to allow release jobs to happen in any master rather > > than lock them to a specific master where we really have a silo rather than > > the whole pool. > > actually, I'd rather have masters that *only* did releases. Yes. There are other advantages to having masters that only do releases, like being able to use a snapshot of releng infra that has been vetted by a staging release + manual testing.
Comment 5•13 years ago
|
||
(In reply to Chris AtLee [:catlee] from comment #3) > (In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #1) > > IMHO the right way is to allow release jobs to happen in any master rather > > than lock them to a specific master where we really have a silo rather than > > the whole pool. > > actually, I'd rather have masters that *only* did releases. Yeah, this is good to have, too. I'm having trouble coming up with a specific use case, but I still feel like this feature could be useful.
Comment 6•11 years ago
|
||
Found in triage. Unclear from the back-forth in this bug as to what the actual objective is here, but regardless, I *think* this is the correct component.
Component: Release Engineering → Release Engineering: Developer Tools
QA Contact: hwine
Assignee | ||
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
Updated•10 years ago
|
Whiteboard: [slavealloc] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2556] [slavealloc]
Comment 7•9 years ago
|
||
WONTFIX in favor of bug 1135818.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Assignee | ||
Updated•7 years ago
|
Component: Tools → General
You need to log in
before you can comment on or make changes to this bug.
Description
•