LEP/OopsDisplay

Not logged in - Log In / Register

OOPS Display/analysis/processing

Contact: RobertCollins
On Launchpad: https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=oops-handling

As a Technical architect
I want oops display/analysis/processing to be scalable, efficient and extensible
so that developers can analyse production issues more efficiently

Rationale

Oopses are a key part of our production issue reaction and analysis workflow, but our current toolchain is missing some features we expect would help us. Improving it will allow developers to gather fresh data more easily.

Our users care that we fix problems promptly, making it easier to fix problems helps us deliver faster fixes to users.

Stakeholders

Other departments at Canonical are interested too

Constraints and Requirements

Must

We need to solve a number of problems:

Launchpad has the following constraints/requirements:

rate on 100million web requests a day (we do 6M a day at the moment, so this is a single order-of-magnitude scaling buffer). (Be prepared for reasonable growth)

UbuntuOne has the following constraints/requirements:

oops)

Nice to have

Must not

Launchpad has this negative constraint:

Out of scope

Subfeatures

Workflows

A user encounters an OOPS; they paste the id into #launchpad, and a Launchpad engineer can look at the OOPS pretty much immediately, and then recommend a workaround to the user, file a bug, or even just sit down and fix the issue.

Success

How will we know when we are done?

The problems listed in the 'need to solve' section are solved.

How will we measure how well we have done?

Thoughts?

-very- early /possible/ design sketch:

LEP/OopsDisplay (last edited 2011-12-12 06:24:37 by lifeless)