Crash database requirements (was: The need for apport hooks (was: Re: SRUs for typo fixes in descriptions))

[Robert Collins]

On Mon, Aug 8, 2011 at 6:25 PM, Christopher James Halse Rogers
<raof at ubuntu.com> wrote:
> I know it's been proposed and discussed previously, and I believe Robert
> Collins both wants something similar for Launchpad and has done some
> work towards making it happen.

I have a draft implementation of a core db server intended for use
with LP's own crash reporting requirements, and hopefully scalable
enough to handle a high volume of reports (e.g. 1M/day).

> I don't know if we've actually written down what we want out of a crash
> database, though.  Do we have a requirements document for one?  If the
> Launchpad team wanted to devote some time to adding a crash database do
> they know what we want out of such a beast?

The LP team doesn't *currently* have working on this in our short term
plans; if the stakeholders wanted to negotiate queue jumping, we could
put a squad on it at the end of the next(ish) project, or some folk
may do something in scratch time (like my experiment with cassandra
has been).

> Is there a LEP for a crash database?  If not, perhaps we could gather
> requirements in this thread and then write one?

Yes, there are two in active discussion I believe:

There is this: https://dev.launchpad.net/LEP/OopsDisplay (ignore the
name, which could be better).

And the Ubuntu folk & the dublin sprint are putting some distro side
needs together - https://wiki.ubuntu.com/CrashTracker - which is on my
TODO list to provide some thoughts on the server design side.

As part of the Launchpad SOA process we'll be splitting out various
crash report tools that are currently part of the LP codebase itself -
into small reusable python modules. I'd be delighted if they are
generic enough to fit in with Ubuntu's needs here - ideally through
migrating parts of apport into using the core facilities [we looked at
using apport for LP's needs, but the bits we need are different enough
that the engineers assessing it decided not to].

-Rob