[Foundations] Release Meeting 2012-08-24

[Evan Dandrea]

On Fri, Aug 24, 2012 at 2:01 PM, Dmitrijs Ledkovs
<dmitrij.ledkov at ubuntu.com> wrote:
> On 24/08/12 13:35, Sebastien Bacher wrote:
>> Le 24/08/2012 14:25, Oliver Grawert a écrit :
>>> "This will let us judge whether the timeouts we're seeing on the month
>>> view and sometimes on the day view are caused by talking to Launchpad"
>> hum, what does that mean exactly? what is missing when using that option?
>>
>
> I think instead of fetching the bug status & other data from launchpad,
> it is using the cache it already had, thus removing the 'timeouts' when
> loading large data (e.g. monthly, all-time views).
>
> Adding ev, to CC to explain.

Thanks Dmitrijs!

Hi Seb,

Right now the website asynchronously loads the contents of the most
common problems table using the web API. This request first gets the
problems that have the highest rate of instances from Cassandra, then
it asks Launchpad for the status of any linked bug and asks what the
most recent published version of the package is. It asks Launchpad for
this information to color the table based on whether we thought a
problem was a possible regression, already fixed, or had disappeared
in the most recent version.

The two Apache servers for errors.ubuntu.com have timeouts in handling
the request. With the addition of talking to Launchpad, we're now
hitting this timeout fairly frequently.

Both parts of this were in need of some alteration and optimization.
The "highest rate of instances" was determined by just looking for any
problem with an instance count greater than 20 in the period
specified. This caused a lot of confusion when people switched to the
12.10 day view and suddenly saw no data (because the problems didn't
have more than 20 instances). This is fixed in trunk. It now takes the
100 problems that have the highest instance count for the specified
period. If seeing more problems than that is a priority, let me know.

The actual fetching of data from Cassandra has been optimized in trunk
by fetching multiple rows at once. This may require some tuning as
fetching multiple rows in a single call can be a very taxing operation
on the database. There are likely to be other ways in which we can
speed this up. This is just the work of part of yesterday.

We use httplib2 for talking to Launchpad's API, as it creates a cache
of etags and uses compression to speed things up. I've made some
changes in trunk to speed this up further, but I'm still looking into
why these queries are still so slow. For now you can use
https://errors.ubuntu.com?launchpad=false, which turns off fetching
the data for possible regressions, fixed bugs, and disappeared
problems from Launchpad. I'm also going to look into separating out
the Launchpad query into another asynchronous call. So the graph will
load with plain text, then you'll get the coloring.

Unrelated, but while I have the attention of the release team, I'm
aware that the colors in the most common problems chart are confusing.
We're working on making their purpose much more obvious. This is what
it looks like in trunk:

http://people.canonical.com/~evand/tmp/errors-design-proposed-20120823-1.png

Thanks!