Closed Bug 658392 Opened 14 years ago Closed 14 years ago

deploy tp5

Categories

(Release Engineering :: General, defect, P2)

Product:
Release Engineering
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: anodelman, Assigned: armenzg)

References

Details

(Whiteboard: [testing][talos])

Patches for buildbot-configs, buildbotcustom and talos in 601798. I will post a new talos.zip. The plan is to start a timer post this deployment, after two weeks with tp4 & tp5 running side by side tp4 can be disabled.
Blocks: 601798
Whiteboard: [testing]
Alice: can this be deployed at any time?
Assignee: nobody → coop
Priority: -- → P3
Whiteboard: [testing] → [testing][talos]
We're blocked on getting some agreement in mozilla.dev.planning as to accepting the increased waittime caused by having tp4 and tp5 running side by side.
Did this get figured out? I think the fastest would be to join in the dev meeting on Tuesday to get the final agreement if there is not a date yet.
I believe the dependency was reversed.
No longer blocks: 601798
Depends on: 601798
I got this wrong. coop is this FIXED? as in deployed to build.m.o?
Blocks: 601798
No longer depends on: 601798
(In reply to comment #6) > I got this wrong. > > coop is this FIXED? as in deployed to build.m.o? AFAIK, no, this is not resolved. Alice: are there dependencies we can add to this bug to track this decision (assuming it's happening in other bugs)?
This is where the discussion should be happening, there are no dependent bugs to my knowledge.
(In reply to comment #8) > This is where the discussion should be happening, there are no dependent > bugs to my knowledge. I have to disagree. I want agreement on http://groups.google.com/group/mozilla.dev.tree-management/browse_thread/thread/20b95f4fff40b35b/3bd0f3a71014df31?lnk=gst&q=tp5#3bd0f3a71014df31 I am adding dependency on bug 659118 since it will add few more slaves for each platform helping with the load. I see June 21st and July 5th coming and I wonder how will it play with deploying schedules.
Assignee: coop → armenzg
Depends on: 659118
Priority: P3 → P2
I don't understand why we would want to add this dependency, when the tp5 deployment is only causing a temporary increase in wait time - not a permanent one. Since it is a temporary hit it should not depend upon permanent hardware alterations.
I believe waiting on more machines (which is happening this week if no delays) will make the decision easier (as we would have more capacity).
I thought that you were doing a rolling roll out - getting it on tracemonkey first. Why block that first step? It would only be on a small section of the test runs and would not involve as large of a wait time increase. That way when the greater amount of hardware becomes available you'll be able to do the complete roll out and get this finished.
OK let's do tracemonkey first which won't require us to get consensus. Can you adjust attachment 531787 [details] [diff] [review] and throw it my way?
No longer blocks: 601798
Depends on: 601798
(In reply to comment #11) > I believe waiting on more machines (which is happening this week if no > delays) will make the decision easier (as we would have more capacity). We've been waiting on new machines for over 6 months. For six months I've heard that we'll have new slaves "any day now" I no longer believe that we can purchase our way out of this hole and I think it's not a viable practice to keep blocking progress on this illusory dream. We are talking about a *temporary increase* as in, an increase that will last for 1-2 weeks while we run both tp4 and tp5 at the same time. After that, we switch to running only tp5 and we no longer have any increase. Do we even have any metrics on how bad this temporary increase would be? Are we making mountains out of molehills here?
(In reply to comment #14) > (In reply to comment #11) > > I believe waiting on more machines (which is happening this week if no > > delays) will make the decision easier (as we would have more capacity). > > We've been waiting on new machines for over 6 months. For six months I've > heard that we'll have new slaves "any day now" I no longer believe that we > can purchase our way out of this hole and I think it's not a viable practice > to keep blocking progress on this illusory dream. > > We are talking about a *temporary increase* as in, an increase that will > last for 1-2 weeks while we run both tp4 and tp5 at the same time. > > After that, we switch to running only tp5 and we no longer have any increase. > > Do we even have any metrics on how bad this temporary increase would be? > Are we making mountains out of molehills here? The new testing pool is far far away (there is need of a colo first to fit them). These are a set of repurposed Rev3 machines from the Win7 64-bit pool so they are real and they are coming to production this week. We don't have to block but they will help to say "hey, we have few more machines and a little bit of more load because of dual running of tp. We (devs) should allow releng/a-team to go ahead and not block them anymore". I don't want to block on it. This is what I see: * Let's get tracemonkey in (I am doing some local testing) * Let's ask anode to verify the runs and say go/no-go to enable it everywhere * Ask drivers to let us run it for two weeks since it works on tracemonkey and at the same time we have some temporal machines that will help us not notice it that much * Enable it dual run for 2 weeks (or less) * Disable tp4 upon anode's approval Sounds good? It is not as much of a load (10-15mins) as mentioned but it has been asked at the time that we have more eyes watching the limited CPU.
Blocks: 601798
Status: NEW → RESOLVED
Closed: 14 years ago
No longer depends on: 601798
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.