Handle "historical" glean metrics file

[Dexterp37]

The scraper currently imports the latest version of glean-parsers. However, if breaking non-backwards compatible format changes are introduced in the parsers, the scraper might break.

We should fix this. Among the possible solutions:

• do version pinning for the parsers;
• have two CI environments;
• include a version in the metrics file.

[mdboom]

I'd think let's version pin glean_parser for now. (Option 1)

For Option 3, We already include the version in the metrics.yaml file, but we're not versioning the schema yet while we're in "cowperson development" mode. Once we start semantic versioning the metrics.yaml schema, we should hopefully get that for free.

[fbertsch]

Currently we ignore historical metrics.yaml files that are not compatible with the current version of glean_parser.

[mdboom]

Now that Fenix is about to enter feature freeze, it seems like a good time to stop making breaking changes in glean_parser (whatever that might mean) so going forward it can handle any valid metrics.yaml -- which might imply versioning metrics.yaml etc.. Does that make sense?

[fbertsch]

@mdboom that does make sense. What I would prefer is for the probe-scraper not to have to deal with any of that, and instead have the metrics.yaml contain an optional version inside of it somewhere (ala circleci) and then the glean_parser be able to handle the version itself. Does that seem reasonable?

Either way, we should have a proposal for this.

[mdboom]

Yeah, that sounds like the right approach (in broad strokes).

[Dexterp37]

@mdboom that does make sense. What I would prefer is for the probe-scraper not to have to deal with any of that, and instead have the metrics.yaml contain an optional version inside of it somewhere (ala circleci) and then the glean_parser be able to handle the version itself. Does that seem reasonable?

Either way, we should have a proposal for this.

There's a third path, which is what the current Desktop parsers do. Parsers can have 2 modes: strict (for things at build time) and relaxed (for parsing out of build time). I'm not saying this is better, just calling it out :)

I'm with @fbertsch on this, I have the feeling that consumers don't need to care about metrics.yaml versioning, that should be an implementation detail for the glean_parser.

This sounds like something for Q3+?