Closed Bug 864418 Opened 11 years ago Closed 11 years ago

Please deploy default browser change to our win8 pool (developed on bug 854905)

Categories

(Infrastructure & Operations :: RelOps: General, task)

x86_64
Windows 8
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: armenzg, Assigned: q)

References

Details

Attachments

(1 file)

I've tested that the change that we deployed to t-w864-ix-001 (bug 854905) works correctly for metro tests and does not cause any regressions to the rest of our test jobs.

I would like to deploy the change to the rest of our win8 test infrastructure.

I will deploy running the metro jobs which should fail (which is fine) until this gets deployed.

Thanks for your help!
Blocks: 847442
Assignee: server-ops-releng → q
Blocks: 864801
Thinking through this there is a condition that could bite us in the future.
 This proof of concept  fix assumes that a nightly build has been installed at least once on the machine. It is entirely possible that a machine could get re-imaged and run an aurora job before a nightly job is ever run causing it to fail. Would it be possible to have the devs write a small installer that just puts in the install hooks for a browser called something specific like "ffdef" or "firefoxmet", etc ? 

 It would only need to register as a browser, add the correct registry entries and point to the correct location where the binaries will be when a build happens. That installer could run as part of the machine build ( or via gpo to catch up the old machines) then register it via the XML default browser fix in GPO.
Flags: needinfo?(jmathies)
The registration the installer does is all registry related, so we could put together a reg script that imported what the nsis installer would import if it ran normally.

I was under the impression that this is what the gpo fix was doing though.
Flags: needinfo?(jmathies)
Depends on: 864940
Ok, we've tested a "register script" in bug 864940 for use in registering the browser at the slave install location.
Wonderful!

What are the next steps? (sorry if I should already know after yesterday's convo).
Would the metro jobs run if I was to run it?
Do we need a new build with the registry that just landed?
Or do we still need a change on the win8 machines done by Q?

The metro tests can run on Cedar (I just triggered Win7, WinXp and Win8 test jobs on that old changeset from Tuesday so we can see them run).
(In reply to Armen Zambrano G. [:armenzg] (Release Enginerring) from comment #4)
> Wonderful!
> 
> What are the next steps? (sorry if I should already know after yesterday's
> convo).
> Would the metro jobs run if I was to run it?
> Do we need a new build with the registry that just landed?
> Or do we still need a change on the win8 machines done by Q?
> 
> The metro tests can run on Cedar (I just triggered Win7, WinXp and Win8 test
> jobs on that old changeset from Tuesday so we can see them run).

We should test this on a clean slave. 

1) import the reg script 
2) do Q's xml thing
3) run metro mochitest tests on the slave through automation using the latest opt build from mc

Can GPO do both steps 1 and 2 on a single slave?
GPO can do 1 and 2 on a single slave. I will take a virgin slave and make it happen.
Great!

FYI: once we have this running on Cedar it will show up in here:
https://tbpl.mozilla.org/?tree=Cedar&jobname=WINNT 6.2 cedar opt test metro-immersive&showall=1

It currently fails until we resolve this bug.
Just to be explicit, this does not have higher priority than fixing the last two imaging issues on the Win7 on iX project.

The meeting we had was to make sure that we would have a clear path forward for Q to be able to tackled when he would have time.

This can be done when there are spare cycles with the other project.
I'm very sorry if this conveyed mixed messages.
Just checking - do you guys think we'll have time to finish this up this week?
Hi Armen, given you points in Comment #8, do you have an estimate as to when this bug will be resolved so we can plan other Metro project work around it.
Flags: needinfo?(armenzg)
Sorry about the delay. Thanks for flagging.

I asked IT to focus on getting Windows 7 running on the new iX hardware since it's been a high profile goal we have been working on at it would improve the Win7 wait times. I don't know how long it will take us to figure the 2 remaining imaging issues. I'm hoping that the work could be figured out this week but I can't speak on behalf of IT.

If I have made the wrong call (put Win7 on iX higher that Metro testing) and make the Metro project to derail, please raise it up at the Tuesday meeting where joduinn could handle the question of prioritization and we would then tell IT to refocus.
Flags: needinfo?(armenzg)
I spoke with joduinn and arr about win7ix VS metro and we have agreed that after I get the 10 machines on bug 829126 it is fine for IT to tackle this Metro bug since the Win7ix dual graphics setup issue could not be resolved very soon.
This was pushed to a freshly imaged machine t-w864-ix-001.wintest.releng.scl3.mozilla.com. Tests should be run to verify. Afterwards the change can be rolled out to all windows 8 machines with a quick GPO move.
I will be testing it in bug 864940.
We're ready for this.
When can you deploy it?
Going out now. Machines will get the update at next reboot.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Component: Server Operations: RelEng → RelOps
Product: mozilla.org → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: