1862002 - Prototype OHTTP in FOG

Status: RESOLVED FIXED

(Toolkit :: Telemetry, task, P1)

Description

[Alessio Placitelli [:Dexter]]

We (myself, Ted Campbell and Wil Stuckey) agreed on a proposal to integrate OHTTP in Firefox on Glean. The

Ted is taking on the initial implementation work.

Comment 1

[Bas Schouten (:bas.schouten)]

Any status updates on this?

Comment 2

[Alessio Placitelli [:Dexter]]

(In reply to Bas Schouten (:bas.schouten) from comment #1)

Any status updates on this?

We are now driving this (client side parts at least). It's happening in Q1.

Comment 3

[Ted Campbell [:tcampbell]]

Attachment: WIP: Bug 1862002 - Prototype Glean / OHTTP integration

Comment 4

[Ted Campbell [:tcampbell]]

Attachment: WIP: Bug 1862002 - Generalize pings.yaml support for OHTTP + glean

Add lints that client_id is disabled, and use the metadata section to track
which pings should use OHTTP.

Depends on D199559

Comment 5

[Ted Campbell [:tcampbell]]

I've attached the straightforward prototype patches that glue OHTTP and Glean together. Once we have the Glean SDK updates to allow disabling the default glean ping metadata, then this should be reasonable to enable.

Comment 6

[Chris H-C :chutten]

Sorry for the delay in responding, I've been swamped with other things. I've been asked to supply a timeline of how this is going to go. Here's my best guess:

1. Implement "no-info for pings" in glean_parser and cut a release
   • Theoretically we could avoid this step by treating it as an extension (like telemetry_mirror), but if we do we run the risk of people applying it to their pings in places where it isn't supported and we'll ignore it -- users will think they have no-info pings, but they'll have full info. So we should treat this more like precise_timestamps.
2. Implement "no-info for pings" in Glean SDK and cut a release.
   • The "don't include info while collecting the ping" part should be fairly straightforward. We have patterns to follow with include_client_id, send_if_empty, and precise_timestamps.
   • We need a way to advertise to the uploader that the ping is no longer a Glean ping. (When we strip the info, the ping doesn't validate against Glean's ping schema and so isn't a Glean ping.) We can't upload this as normal, and we need some way to advertise which of these pings are like this so that uploaders who don't know how to handle this can properly drop them.
     • This means we need to change the storage of pings on disk, as the ping that was collected might no longer be in the binary when the ping body is uploaded. (And, of course, we need to maintain backwards compatibility for pings of the earlier shape)
     • From there we'll need to change the signature for PingUploader::upload to provide this ping configuration information ("Do not send to incoming.tmo in the normal way as it'll error") and offer a new UploadResult for apps that don't understand pings of this configuration ("If you don't have custom handling for pings like this, return this specific error"). This'll necessitate a major version bump for the SDK.
3. Vendor the new Glean SDK version into Firefox Desktop
   • Adapting from the prototype patches, we'll swap out the path regex for checking the newly-passed configuration information. The ViaductUploader will need access to the application id from FOG init. We'll need a list of pings from codegen that want to be sent as ohttp.
   • Question for Ted: Is it meaningful that the metadata proposal and prototype split the concepts of "pings that have no *_info sections" from "pings sent over OHTTP"? Normal Glean ingestion has no interest in pings without *_info. And I reckon OHTTP has no interest in pings with them? If there is a distinction, then FOG will need to codegen a list of pings with OHTTP and compare the upload call's ping to the list to ensure a) it has no *_info, and b) it's on the list of OHTTP-transferable doctypes.

And that'll get Firefox Desktop the capability to send *_info-less pings over OHTTP. Then validation and verification can begin and all that (but I'll count that as out of scope for this timeline).

I expect this to take no more than three weeks, but definitely more than one week, assuming we can dedicate most of our attention to it.

Comment 7

[Chris H-C :chutten]

There's also additional pipeline work as OHTTP as a transport (though it requires that these not-Glean pings be sent to the OHTTP endpoint) will send these not-Glean pings to Mozilla soon after receipt. This work of ingesting these OHTTP-proxied payloads, too, is not included in the estimate or order of work.

Also, this work may suggest a preference for whether OHTTP and no-info pings should be the same thing or can be two separate things (maybe e.g. having no-info schemas only available on the endpoint receiving the OHTTP-proxied payloads is meaningfully easier or harder), so this question might come up again for someone who's not Ted.

Comment 8

[Chris Bellini (:cbellini)]

Would it be fair to say this could become available to use in 125, or is 124 still a possibility?

Comment 9

[Ted Campbell [:tcampbell]]

(In reply to Chris H-C :chutten from comment #6)

* **Question for Ted:** Is it meaningful that the metadata proposal and prototype split the concepts of "pings that have no `*_info` sections" from "pings sent over OHTTP"? Normal Glean ingestion has no interest in pings without `*_info`. And I reckon OHTTP has no interest in pings _with_ them? If there is a distinction, then FOG will need to codegen a list of pings with OHTTP and compare the upload call's ping to the list to ensure a) it has no `*_info`, and b) it's on the list of OHTTP-transferable doctypes.

It is totally fine for OHTTP to imply no info data. That solves all near term use cases, and if we want to get fancier it would probably still require a "partial info" mode to be designed and implemented at a later date. I think of this more of "metadata mode = { standard, reduced_with_ohttp, minimal_with_ohttp }" or something of that nature rather than individual knobs. Glean and data-pipeline folks would have better instincts about the details than me though.

Comment 10

[Chris H-C :chutten]

(In reply to Chris Bellini (:cbellini) from comment #8)

Would it be fair to say this could become available to use in 125, or is 124 still a possibility?

We have 8 days until soft code freeze, so it's still safest to assume 125.

Comment 11

[Chris H-C :chutten]

Attachment: Bug 1862002 - Clippy fixes for glean/src/lib.rs r?perry.mcmanis!

Comment 12

[Chris H-C :chutten]

Attachment: Bug 1862002 - Update old pings.yaml comment from 2020 r?perry.mcmanis!

Comment 13

[Chris H-C :chutten]

Attachment: Bug 1862002 - Prototype OHTTP in FOG r=wstuckey!,travislong!

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/39425b9e5663
Clippy fixes for glean/src/lib.rs r=perry.mcmanis
https://hg.mozilla.org/integration/autoland/rev/712db400d295
Update old pings.yaml comment from 2020 r=perry.mcmanis
https://hg.mozilla.org/integration/autoland/rev/cf0ec10fbd23
Prototype OHTTP in FOG r=wstuckey,TravisLong

Comment 15

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fe11d0f3c54d
Backed out 3 changesets for causing android xpcshell failures on test_OHTTP.

Comment 16

[Cosmin Sabou [:CosminS]]

Backed out 3 changesets for causing android xpcshell failures on test_OHTTP.

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=cf0ec10fbd235c44fbc7428537586dc626d899f7&selectedTaskRun=cpidVnXFQzuHLGHX0HaQlw.0

Failure log: https://treeherder.mozilla.org/logviewer?job_id=450120389&repo=autoland

Backout link: https://hg.mozilla.org/integration/autoland/rev/fe11d0f3c54d

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2c776b79ef63
Clippy fixes for glean/src/lib.rs r=perry.mcmanis
https://hg.mozilla.org/integration/autoland/rev/949253568be3
Update old pings.yaml comment from 2020 r=perry.mcmanis
https://hg.mozilla.org/integration/autoland/rev/161636768792
Prototype OHTTP in FOG r=wstuckey,TravisLong

Comment 18

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/2c776b79ef63
https://hg.mozilla.org/mozilla-central/rev/949253568be3
https://hg.mozilla.org/mozilla-central/rev/161636768792