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 8:05 PM, Rick Spencer <rick.spencer at canonical.com> wrote:
> On Mon, 2011-08-08 at 19:44 +1200, Robert Collins wrote:
>> On Mon, Aug 8, 2011 at 6:25 PM, Christopher James Halse Rogers
>> <raof at ubuntu.com> wrote:
>> 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).
>>
>
> I'm wondering why the launchpad team would work on this. It seems that
> the desire is to collect the crash data outside of lp bug reports.

LP isn't defined by the features we have - they shift over time :)

> Am I missing something?

Theres a few potential reasons.

One is very simple: we need it ourselves; we logged about 14 thousand
crash reports yesterday from Launchpad itself into our first-gen crash
database (e.g. https://lp-oops.canonical.com/oops.py/?oopsid=1971CBA7).
We have some automated analysis of this today but its a kludgy system:
high latency, no adhoc analysis, single tenant (and as Launchpad moves
to a more SOA model multitenancy or something like it will matter
more), no efficient searching. This is much the same reason that
Mozilla has built a crash database, for instance.

Secondly, one of the things Launchpad exists to do is to provide a
solid platform for folk writing software - I see a generic, extensible
crash database as something many projects would benefit from. That
would be a separate project of course, but a relatively small step up
from a just-for-our-own-crashes service. Right now I know of the
following Canonical sponsored-or-related projects which could use such
a service: t Ubuntu one (server), landscape (server) and Canonical ISD
(SSO etc). Not to mention Ubuntu, of course. I can well imagine
projects like drizzle, openerp or openstack, wanting to gather
anonymised crash data even when folk are running snapshots, or
unpackaged builds. (Packages on Ubuntu would naturally get reports
gathered without the upstream being a direct user, but there are lots
of unpackaged use cases for regular software, let alone web server
stacks (consider all the virtualenv based django deployments out
there...).

Thirdly, as a team Launchpad /started/ as a project to satisfy the
server-side infrastructure needs of Ubuntu; supporting Ubuntu's
collaboration with Debian, with Upstream, supporting Translations of
Ubuntu, and over time this has grown - soyuz was written for Ubuntu,
blueprints for UDS. Of course, Launchpad has users beyond Ubuntu, in
our capacity as a hosting forge for upstreams, and as a hosting site
for derivatives like the OEM flavours and Linaro, but providing
services that are primarily, or even exclusively, needed by Ubuntu is
well within our mandate. The crash database concept is clearly not one
of these exclusively-for-Ubuntu cases (even without aiming at
multitenancy, LP needs one itself). We had painted ourselves into a
process corner a while back which lead to us having to push back on
the amount of things we undertake... but the team have been working
fearlessly to fix that, and I think we're over the hump now - on the
way back to short, high quality and fast iterations.

Fourth, the total workflow desired is to capture crashes and derive
bug reports from that: defining Launchpads relationship to crashes by
our current implementation would be overly strict IMO: I think LP will
*need* to be involved, at minimum, in the crashdb -> bug mapping
process / mechanism (e.g. for questions like 'which crash reports are
related to this bug' to be answered in the web UI). It doesn't matter
whether the crash database is maintained by a different team or not,
we'll need integration.

Lastly, while the particular form of scalability needed is different
to that needed by Launchpad's existing services, writing web services
is what the Launchpad team is all about, and we've several services
that have similar scaling needs (though different in detail and in
likely implementation) - things like the librarian and codehosting.
We're already planning on how we will split those out into separate
web services which can be scaled separately and reused more
effectively.

-Rob