With bug 1064333 landed we should watch out for the FHR submissions still looking sane. I'm not sure if that covers everything, but i can think of: * keeping an eye out for drops in submission volume * validity of submissions should stay stable too (post pre- and post-processing) * any jumps in orphaning (which may point to client id implementation issues)

Not sure at all if that was the right component. tmary, can you see who can look into this please? We want to uplift bug 1064333 to Aurora soonish. I don't know if we have enough volume on Nightly to see anything other than major volume drops etc., but i'd really like at least a quick sanity check on the data before uplifting.

I suspect tmary can help us with submission volume, and bcolloran is the right person to check on other things like orphaning rates. This doesn't need to be private.

That is roughly what i got out of an email thread; tmary said to file a bug for him to ping the right people.

We aren't currently using clientID in the deorphaning pipeline in any way. Unless this touches the existing docID code, orphaning rates should not be affected (of course, we've been bitten by "should"s before, so I'll keep a watching). Is the docID code altered by these changes?

Re submission volumes, counting submissions using 'User-Agent' header seems reasonable. Results from the Hive query (hive -e "select ds, count(*) from v2_raw_logs where domain='fhr.data.mozilla.com' and ds>='2014-10-01' and user_agent like '%Firefox%36.0%' group by ds order by ds;") 2014-10-01 2 2014-10-02 2 2014-10-03 2 2014-10-04 2 2014-10-05 1 2014-10-06 3 2014-10-07 3 2014-10-08 2 2014-10-09 3 2014-10-10 2 2014-10-11 1 2014-10-12 2 2014-10-13 601 2014-10-14 20878 2014-10-15 43999 2014-10-16 50060 2014-10-17 50052 2014-10-18 44123 2014-10-19 45499 2014-10-20 55699 2014-10-21 56448 --

The change should be in Nightly for 2-3 days now - can we do the checks now? Thanks.

(In reply to Georg Fritzsche [:gfritzsche] from comment #6) > The change should be in Nightly for 2-3 days now - can we do the checks now? > Thanks. (Ref Comment#5) 2014-10-21 56448 2014-10-22 55750 2014-10-23 53739 2014-10-24 52632 2014-10-25 47064 2014-10-26 48688 --

unfortunately, i'm not geared up to be able to detect changes in the orphaning rate based on 2-3 days of nightly data. it's kind of a research project, so i need to know what the potential risk of the patch is before i drop everything to initiate that research. so, i ask again: We aren't currently using clientID in the deorphaning pipeline in any way, nor is the clientID used in any part of the server-side intake or processing (to the best of my knowledge)-- we still use the docID for record deletes et cetera. So unless these changes touche the existing docID code, orphaning rates should not be affected. Is the docID code altered by these changes, or do you just read the clientID? If the latter, I consider this low-risk, in which case I recommend watching the numbers tmary is able to generate.

Sorry for missing the question before - the doc-id was not touched. This touches code paths around client-side state persistance though - i don't expect it to break anything, but i'd prefer to be sure when we're basing decisions on that data. If there's currently no way for short-term checks though i guess we'll move forward based on tmarys data. Please keep an eye out for possible impact.