Created attachment 533774 [details] [diff] [review] staging_cofig.py - allow all slaves It is not the first time that I have needed to move a slaves from production into staging because the staging were wedged or even try to use the slave#10 from preproduction. The problem I would face is that it would take me some time to notice that the slave was not being able to take jobs.
Attachment #533774 - Flags: review?(coop)
I thought we were getting rid of staging? And that development systems would use the same *_config.py as preproduction (which includes all slaves)?
Comment on attachment 533774 [details] [diff] [review] staging_cofig.py - allow all slaves Patch is fine, but I think Dustin is right in comment 1.
Attachment #533774 - Flags: review?(coop) → review+
Should we remove the staging files so we don't use them?
Summary: Allow moving rev3 machines from production to staging if it is needed → Allow moving rev3 machines from production to staging/preproduction if it is needed
Assignee: nobody → armenzg
Status: NEW → ASSIGNED
Priority: -- → P2
As much as I would love to get to this there's much assigned to me at the moment. Putting it into the future.
Status: ASSIGNED → NEW
Do we still want to do away with staging? Does that mean we'd be relying on preproduction to test release changes?
Component: Release Engineering → Release Engineering: Machine Management
OS: Mac OS X → All
Priority: P4 → --
QA Contact: release → armenzg
Hardware: x86 → All
This was for the sake of being able to move a slave to preproduction and test that is good to be put back in production. What I do instead is to put them in my own testing master and then be happy about it when it takes jobs appropriately.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.