Closed Bug 795051 Opened 9 years ago Closed 9 years ago

provide buildID, version, and dogfooding_prerelease_id in URL for b2g update requests

Categories

(Firefox OS Graveyard :: General, defect, P1)

defect

Tracking

(blocking-kilimanjaro:+, blocking-basecamp:+, firefox18 fixed, firefox19 fixed)

RESOLVED FIXED
blocking-kilimanjaro +
blocking-basecamp +
Tracking Status
firefox18 --- fixed
firefox19 --- fixed

People

(Reporter: lsblakk, Assigned: marshall)

References

Details

Attachments

(3 obsolete files)

from bug 759910: "currently the os version (or B2G version) is set in b2g/confvar.sh, and the b2g/chrome/content/settings.js is doing a hack of writing these information into IndexedDB at launch time. Please reference bug 790158 for more details, thanks."

Also there is https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIXULAppInfo

In the update URL (for both nightly and stable channels), at least until we ship a v1.0, we'd like to have the following added to the URL:

?build_id=<appBuildID>&version=<appVersion>&dogfooding_prerelease_id=<asset_tag>

The final of the three parameters can be appended from an url override in a custom-prefs.js file we add to the gaia install:

user_pref("app.update.url.override", "asset_tag");

but the build ID and version will need to be dynamically grabbed from the device each time it pings for updates so we can track the data.
Summary: provide buildID and dogfooding_prerelease_id in URL for b2g update requests → provide buildID, version, and dogfooding_prerelease_id in URL for b2g update requests
Unfortunately, I don't think the "app.update.url.override" pref works that way. It's just override's the system's update URL, and doesn't append anything to it.

Channel, Build ID, and App Version can already be injected with the current AUS. Assuming you know a valid dogfooding prerelease ID, you should be able to insert this pref into the device's profile in /data/b2g/mozilla/<profile>.default/prefs.js:

user_pref("app.update.url.override", "http://update.boot2gecko.org/%CHANNEL%/update.xml?build_id=%BUILD_ID%&version=%VERSION%&dogfooding_prerelease_id=<REPLACE_ME_WITH_DOGFOODING_ID>")
Blocks: b2g-gecko-updates
No longer blocks: b2g-fota-updates
OK cool.  Yes, we will have the dogfood prerelease ID set on each phone as it is deployed. 

Let me see if I have this right then, from the perspective of a Desktop Support staff person who will unbox and prepare a phone for deployment.  They should:

* install B2G
* create a Gaia profile
* insert in /data/b2g/mozilla/<profile>.default/prefs.js:

user_pref("app.update.url.override", "http://update.boot2gecko.org/%CHANNEL%/update.xml?build_id=%BUILD_ID%&version=%VERSION%&dogfooding_prerelease_id=<REPLACE_ME_WITH_DOGFOODING_ID>")

And this info will show up in the apache logs?
Just a few minor changes:

* install / flash B2G
* let B2G bootup normally, the gaia profile should be setup automatically by the time you see the lockscreen
* insert the user_pref into /data/b2g/mozilla/<profile>.default/prefs.js
* restart b2g (adb shell "stop b2g; start b2g")

Jonathan, can you confirm the various query string values will show up in the apache access log?
(In reply to Marshall Culpepper [:marshall_law] from comment #3)
> Just a few minor changes:
> 
> * install / flash B2G
> * let B2G bootup normally, the gaia profile should be setup automatically by
> the time you see the lockscreen
> * insert the user_pref into /data/b2g/mozilla/<profile>.default/prefs.js
> * restart b2g (adb shell "stop b2g; start b2g")
> 
> Jonathan, can you confirm the various query string values will show up in
> the apache access log?

Yes, they will.
/system/b2g/defaults/pref is a better location to drop a pref file into and should be resistant to /data partition wipes.
(In reply to Michael Wu [:mwu] from comment #5)
> /system/b2g/defaults/pref is a better location to drop a pref file into and
> should be resistant to /data partition wipes.

Yes, but make sure you use a pref(...) and not a user_pref(...) here.
Attached patch update url custom token - v1 (obsolete) — Splinter Review
This allows us to pass along the dogfooding ID for each B2G device in the update URL
Attachment #665762 - Flags: review?(robert.bugzilla)
Attached file example dogfood setup script (obsolete) —
This script will setup b2g with a custom update URL based on the dogfood ID passed as the first argument. (This requires the attached patch)
Comment on attachment 665762 [details] [diff] [review]
update url custom token - v1

We typically just add the extra fields to the app's app.update.url preference. Wouldn't that suffice for this case?

Minusing to get an answer to the above.
Attachment #665762 - Flags: review?(robert.bugzilla) → review-
Assignee: nobody → marshall
(In reply to Robert Strong [:rstrong] (do not email) from comment #9)
> We typically just add the extra fields to the app's app.update.url
> preference. Wouldn't that suffice for this case?
> 
> Minusing to get an answer to the above.

There are a few reasons why we can't do this unfortunately:
- For the B2G dogfooding program, we need %CUSTOM_VALUE% to be unique to each device so we can track who is and isn't getting updates.
- The current B2G update URL is not final, and will likely change a few times. This means the URL and the dogfood ID to be separate.
- When the dogfooding program is over, we need a way to remove the ID with a system update. 

The solution I'm proposing utilizes auto-loading of pref.js files in /system/b2g/defaults/pref. Since this directory is under /system/b2g, we can have a system update remove or add files as we need. 

With this patch, I can:
- Provide the dogfood ID ("asset tag") as the app.update.url.customValue pref in defaults/pref/asset_tag.js
- Set app.update.url with %CUSTOM_VALUE% in defaults/pref/dogfood.js
- When our update URL changes, ship an update with a new defaults/pref/dogfood.js
- When the dogfooding program ends, ship a new update that removes defaults/pref/dogfood.js and defaults/pref/asset_tag.js
I think you can accomplish the same thing with the distribution.id preference
Comment on attachment 665762 [details] [diff] [review]
update url custom token - v1

I'm ok with this. Would be nice to update the existing tests to include this but I know you are busy with blockers so I'm ok doing that in a followup bug.
Attachment #665762 - Flags: review- → review+
(In reply to Robert Strong [:rstrong] (do not email) from comment #11)
> I think you can accomplish the same thing with the distribution.id preference

Oh, nice. I would be fine re-using this, actually. It sounds like we may not need a platform patch after all.. thanks for the pointer!

> I'm ok with this. Would be nice to update the existing tests to include this
> but I know you are busy with blockers so I'm ok doing that in a followup bug.

Now that you've r+, we may not need this after all :) I'm going to test this real quick locally, but I'm optimistic this will get us what we want..
Comment on attachment 665762 [details] [diff] [review]
update url custom token - v1

Cancelling the patch, as it's no longer necessary
Attachment #665762 - Attachment is obsolete: true
Attached file dogfood setup script (obsolete) —
This script should give us the flexibility we need without patching Gecko..
Attachment #665763 - Attachment is obsolete: true
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Comment on attachment 666023 [details]
dogfood setup script

I've moved the dogfood setup script to a new git repository since we've needed more tweaks since this was resolved:

https://github.com/mozilla-b2g/dogfood-setup
Attachment #666023 - Attachment is obsolete: true
Hello again - I've tested this on today's build with the force-update-check.sh on a device that I ran the setup script on with asset tag 12345

In the update_access_log I see:

63.245.220.224 - - [10/Oct/2012:17:18:43 +0000] "GET /nightly/update.xml HTTP/1.1" 200 571
63.245.220.224 - - [10/Oct/2012:17:22:10 +0000] "GET /nightly/b2g_update_2012-10-10_084604.mar HTTP/1.1" 200 42843210
63.245.220.224 - - [10/Oct/2012:17:24:49 +0000] "GET /nightly/b2g_update_2012-10-10_084604.mar HTTP/1.1" 206 42326865
63.245.220.224 - - [10/Oct/2012:17:28:55 +0000] "GET /nightly/b2g_update_2012-10-10_084604.mar HTTP/1.1" 206 40196130
63.245.220.224 - - [10/Oct/2012:17:31:00 +0000] "GET /nightly/b2g_update_2012-10-10_084604.mar HTTP/1.1" 206 40156624
63.245.220.224 - - [10/Oct/2012:17:32:32 +0000] "GET /nightly/b2g_update_2012-10-10_084604.mar HTTP/1.1" 206 40093760
63.245.220.224 - - [10/Oct/2012:17:36:06 +0000] "GET /nightly/b2g_update_2012-10-10_084604.mar HTTP/1.1" 206 38560716
63.245.220.224 - - [10/Oct/2012:18:13:09 +0000] "GET /m2.5/updates.xml HTTP/1.1" 404 301
63.245.220.224 - - [10/Oct/2012:20:02:25 +0000] "GET /stable/update.xml?build_id=20121010071243&version=19.0a1&dogfood_id=12345 HTTP/1.1" 200 592


So it looks like asking if there are updates available doesn't include the dogfooding id, but once a download is requested, that it is there (which is awesome).  Can we put the id in the request as well to give us better metrics on how often each phone is asking for updates, what they get offered, and if they start to download it (not sure if we can also show from logs if they are successful in completing that download, but at least the next time their device pings for an update we should be able to see what version they are trying to update from).

Does that make sense? Let me know what is possible here - there is no such thing as too many requests that include the ID as far as I'm concerned.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Sorry for the confusion, I am aware now (thanks Marshall) that the GET update.xml url *is* the request ping and then later in the log there is now:

"GET /stable/b2g_stable_update_2012-10-10_125830.mar HTTP/1.1" 200 42925297

which is getting the download for the device - so really the question is: can the ID be slotted into that URL too?
Since update request does in fact contain this ID, I'm re-resolving this bug and opening a new bug to address the MAR request.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Blocks: 800118
You need to log in before you can comment on or make changes to this bug.