1512039 - Stub installer support for installing AArch64 builds

Status: RESOLVED FIXED

(Firefox :: Installer, enhancement, P1)

Description

[Molly Howell (she/her) (mostly inactive)]

Once we have AArch64 builds available, the stub installer needs to support selecting the AArch64 platform to install on supported systems, in addition to x86 or x86-64. My guess is that we would want to select that build on every AArch64 Windows system, regardless of RAM or any of the other requirements we have for selecting x86-64.

Fortunately I don't think this requires building either installer as a native AArch64 binary, because of the x86 emulation layer that Windows provides.

Comment 1

[Molly Howell (she/her) (mostly inactive)]

This is blocked on having this platform actually available in Bouncer, but once that's up it should be a very small change that's needed here.

Comment 2

[Nathan Froyd [:froydnj]]

(In reply to Matt Howell (he/him) [:mhowell] from comment #1)
> This is blocked on having this platform actually available in Bouncer, but
> once that's up it should be a very small change that's needed here.

Apologies for ignorant questions, but do we have a separate bug for the Bouncer (what is Bouncer?) support, or does that bug live in a separate place, like Github?

Comment 3

[Molly Howell (she/her) (mostly inactive)]

Bouncer is the service that takes a download URL like "https://download.mozilla.org/?product=firefox-stub&os=win&lang=en-US" and redirects it to a canonical CDN path like "https://download-installer.cdn.mozilla.net/pub/firefox/releases/63.0.3/win32/en-US/Firefox Installer.exe", after running some rules to resolve things like the latest version number that should be made available. The stub installer uses that kind of download URL to make sure that it's always installing the latest available version for its channel, regardless of when the stub itself is from. The Bouncer code lives at https://github.com/mozilla-services/go-bouncer, but it's very data-driven and I'm not 100% sure what the source of its data is; hopefully it's Buildhub or something adjacent, because in that case we would get all this for free out of the existing releng machinery as soon as we have nightly builds running.

Comment 4

[Molly Howell (she/her) (mostly inactive)]

Attachment: Bug 1512039 - Allow the stub installer to detect and download the AArch64 Windows build. r=agashlin

This patch also removes the last vestiges of the old architecture dropdown
structure, and removes a use of GetBinaryTypeW because it doesn't seem to
return a useful result for any ARM ISA.

Comment 5

[Molly Howell (she/her) (mostly inactive)]

We now have good Buildhub records for aarch64 (like https://buildhub.prod.mozaws.net/v1/buckets/build-hub/collections/releases/records/firefox_nightly_2019-01-07-09-30-40_66-0a1_win64-aarch64_xh) so I had hoped that maybe that would be enough to get Bouncer URL's of the form http://download.mozilla.org/?product=firefox-nightly-latest-ssl&os=win64-aarch64&lang=en-US to start working, but that one 404's still. I'm pretty clueless about Bouncer though; oremj, are you the person to ask about getting that support in, or do you know who is?

Comment 6

[Molly Howell (she/her) (mostly inactive)]

Also, If the problem is just that there's something wrong with that URL and a different one would work, I can easily change any part of it.

Comment 7

[Jeremy Orem [:oremj]]

Releng handles administration of bouncer products/oses/etc.

Comment 8

[Jordan Lund (:jlund)]

Rail asked me to look at this yesterday as I'm currently on hook this cycle for product requests. I'll configure Bouncer tomorrow so it supports aarch64

Comment 9

[Jordan Lund (:jlund)]

I've manually added 4 new locations for win64-aarch64:

https://bounceradmin.mozilla.com/admin/mirror/location/51281/
https://bounceradmin.mozilla.com/admin/mirror/location/51282/
https://bounceradmin.mozilla.com/admin/mirror/location/51283/
https://bounceradmin.mozilla.com/admin/mirror/location/51284/

Verified http://download.mozilla.org/?product=firefox-nightly-latest-ssl&os=win64-aarch64&lang=en-US resolves now.

mtabara: I'm not sure if adding new nightly locations:

1. breaks bouncer check assertions? In either our automation or Bouncer's monitoring
2. aarch64 locations needs to be added to our newly automated bouncer version bump logic that gets actioned once a cycle?

Comment 10

[Molly Howell (she/her) (mostly inactive)]

Confirmed that the URL does indeed resolve, and also that the attached patch now installs the correct build. Thanks Jordan!

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/47b94d26f8a5
Allow the stub installer to detect and download the AArch64 Windows build. r=agashlin

Comment 12

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/47b94d26f8a5

Comment 13

[Mihai Tabara [:mtabara]⌚️GMT]

(In reply to Jordan Lund (:jlund) from comment #9)

I've manually added 4 new locations for win64-aarch64:

https://bounceradmin.mozilla.com/admin/mirror/location/51281/
https://bounceradmin.mozilla.com/admin/mirror/location/51282/
https://bounceradmin.mozilla.com/admin/mirror/location/51283/
https://bounceradmin.mozilla.com/admin/mirror/location/51284/

Verified http://download.mozilla.org/?product=firefox-nightly-latest-ssl&os=win64-aarch64&lang=en-US resolves now.

Thank you for adding these and helping unblock this last week.

mtabara: I'm not sure if adding new nightly locations:

1. breaks bouncer check assertions? In either our automation or Bouncer's monitoring

It doesn't but it shouldn've. We have safeguards in place to ensure the payload + version coming from tree match certain regexes and are correct against what we do have in bouncer. But this usecase isn't covered in bouncerscript and it could. I'll file a separate bug for this to describe the issue and track the problem.

2. aarch64 locations needs to be added to our newly automated bouncer version bump logic that gets actioned once a cycle?

Yes, they should. Otherwise, after the next mergeduty bump they will still serve the old value.
Since I'm doing prepping work for mergeduty anyway this week, I can piggyback on the aforemention up-to-be-filled bug.