Closed Bug 1246183 Opened 9 years ago Closed 7 years ago

Add FoxBox as a new product for Socorro

Categories

(Socorro :: General, task)

Product:
Socorro
Component:
General
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: Yoric, Unassigned)

References

Details

(Not entirely sure it's the right component) We're creating a new product that should eventually upload crash stats. It's called FoxBox. I assume we need to add it in Socorro somewhere. What else should we do?
For most other products featured on crash-stats we pick up new versions and buildIDs by scraping http://archive.mozilla.org/ Is FoxBox going to be made available that way?
I'm not familiar with archive.mozilla.org. FoxBox is being developed on github, in Rust, so I don't know if that's compatible with what you have in mind.
Flags: needinfo?(peterbe)
(In reply to David Rajchenbach-Teller [:Yoric] (please use "needinfo") from comment #2) > I'm not familiar with archive.mozilla.org. FoxBox is being developed on > github, in Rust, so I don't know if that's compatible with what you have in > mind. Actually, I've never understood why we don't just make the versions based on what's coming in on crashes. Kairo, why do we need to know the products versions beforehand? David, Is FoxBox already sending crashes to us via Breakpad?
Flags: needinfo?(peterbe)
Not in the least. We only started coding a few days ago and we haven't even attempted to make it work with Breakpad. I'm figuring that I needed to discuss with you guys to find out what kind of id we needed to provide.
(In reply to Peter Bengtsson [:peterbe] from comment #3) > Kairo, why do we need to know the products versions beforehand? Not sure if we do at all, I think the only thing we actually need them for is matviews and website navigation. Also, before we add anything, I'd prefer if we can see some example crash reports from the product to see what the data looks like and what we need to get added. Also, AFAIK, Super Search can do search just fine for product names that are not in our official list of products, so IMHO, we should not add anything officially before this actually becomes a viable product and emerges out of a purely experimental state (which it currently is in).
As a example for the last paragraph of comment #5, you can easily do https://crash-stats.mozilla.com/search/?product=Test or https://crash-stats.mozilla.com/search/?product=Sunbird or https://crash-stats.mozilla.com/search/?product=CASecureBrowser8.0 which all are not products we have in our official list on Socorro. I think searches like this should be enough for getting an experimental product started on its way.
(In reply to Peter Bengtsson [:peterbe] from comment #3) > Actually, I've never understood why we don't just make the versions based on > what's coming in on crashes. We get a lot of garbage coming in, and I think we didn't necessarily have all the information we wanted to by just looking at crashes. That said, let's not make this bug about that.
Ok, so we can just upload with ids "FoxBox-server", "FoxBox-driver", etc., for instance?
Just chose what you think fits well and use it - esp. as long as you're in an experimentation phase, do the same with those product names - as long as they don't conflict with something else, it's fine. And use Super Search for getting the data you need (there's also an API you can use to get quite a bit of interesting stuff if you like). Once the project may stabilize into a more mature product, we can think about actually adding it as a product into all the navigation and stuff. For now, we should use Super Search heavily and be just as experimental with this as with the project itself. :)
Our collector has a couple of rules that get applied to incoming crashes. https://github.com/mozilla/socorro/blob/1a6ae3f5543768c77c2bad3af2e0cf6b0b9761c7/socorro/collector/throttler.py#L47-L48 It acts to do two things in one algorithm. 1) reject those whose ProductName field in the incoming JSON blog is not recognized at all 2) reject some (10%) if the ProductName == Firefox. So to start collecting FoxBox crashes, all we need to do is add another entry to that list of python code and restart the servers.
Umm, we should never "reject" crashes. We should always collect everything and process everything except the 90% of Firefox release channel crashes.
Also, what you say is not particularly right either, as when you read that code, it's way more complicated. We for example always process all crashes that are on aurora, beta, or nightly* channels, or where the version contains letters, or where the product name starts with a T, S, or C. All that said, let's 1) simplify this and 2) take it to a different bug.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #12) > Also, what you say is not particularly right either, as when you read that > code, it's way more complicated. We for example always process all crashes > that are on aurora, beta, or nightly* channels, or where the version > contains letters, or where the product name starts with a T, S, or C. > > All that said, let's 1) simplify this and 2) take it to a different bug. Lars tells me that, actually, the last line just means it will not be processed. But it will be stored in S3 and ES. Correct, lars?
Flags: needinfo?(lars)
(In reply to Peter Bengtsson [:peterbe] from comment #13) > Lars tells me that, actually, the last line just means it will not be > processed. But it will be stored in S3 and ES. That's what I expect. We still should adjust those rules, but not in this bug.
(In reply to Peter Bengtsson [:peterbe] from comment #13) > (In reply to Robert Kaiser (:kairo@mozilla.com) from comment #12) > > Also, what you say is not particularly right either, as when you read that > > code, it's way more complicated. We for example always process all crashes > > that are on aurora, beta, or nightly* channels, or where the version > > contains letters, or where the product name starts with a T, S, or C. > > > > All that said, let's 1) simplify this and 2) take it to a different bug. > > Lars tells me that, actually, the last line just means it will not be > processed. But it will be stored in S3 and ES. > Correct, lars? This is correct that it will be collected but not flagged for processing, such crashes will be stored in S3 "raw crashes" but not in ES (this is only for processed crashes). The vetting of incoming crashes against data on archive.m.o is used by Postgres primarily, to avoid having to generate reports for garbage. It's also to handle quirks in the Mozilla release system like the way Beta works. Right now Postgres controls what appears in the UI, and it hides products that don't have any valid-looking crashes, so you either need to fake releases_raw inserts or fix Socorro so this is no longer the case. I think the latter is the better long-term fix, this is something every single install outside of Mozilla has to deal with right now. If you agree, I'd file a new bug and make a clean break with the current way of adding new products, and document it as the default. Also consider changing the admin UI, which currently hands this off to Postgres stored procedures (one for adding new products, one for adding new versions which ftpscraper calls).
So, David, You can start sending in crashes when you're ready. We'll chat again when it comes time to add it as a recognized product (so it appears in the relevant drop-downs).
Flags: needinfo?(lars)
Depends on: 1247300
I filed bug 1247300 for changing the throttle rules, that should be all we need for now and should enable more such experiments, which we can expect with what Connected Devices does right now.
David. My bad. I misinterpreted the state. ANY crash coming in would be stored in S3 (the true source) BUT until we fix https://bugzilla.mozilla.org/show_bug.cgi?id=1247300 the crash will not be stored in ElasticSearch which is sad because we would not be able to use SuperSearch to query aggregates around FoxBox.
I expect bug 1247300 will hang up for a while while I determine the risk of opening up collection so broadly. We may want to proceed another way.
We probably should add "FenneciOS" and whatever name this experiment and others out of Connected Devices have with explicit 100% rules in that "throttler" code for now, and then hopefully remove them with the rework in bug 1247300.
I'm pretty sure FoxBox is not a thing anymore. Given that, I'm going to mark this as WONTFIX. If that's wrong, please re-open.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Sadly, you're entirely right.
You need to log in before you can comment on or make changes to this bug.