launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Wed, Oct 19, 2011 at 3:33 AM, Robert Collins
<robertc@xxxxxxxxxxxxxxxxx> wrote:
> This will let you populate bson oopses yourself, which will simply
> show you how binary they are (though still greppable via grep) and get
> a feeling for how much adhoc python you'd want to be able to do a
> sensible console map-reduce over them :)
>
> It will also let you see how convenient getting a development OOPS up
> in oops-tools is : now I can do this, I'm going to be doing it all the
> time, just because of the sweet sweet query collation.

So, I'm landing the result of all this work. Due to a
failure-to-notice the initial landing will dramatically impede test
suite performance; I believe the solution is easy and have a branch
prepped to land straight away to fix this - so please let that second
landing happen before frying me :).

Our production environment is ready-to-roll with AMQP OOPSes: the new
open source oops-tools stack is live on devpad, and the rabbit
configuration to have appropriat exchanges and queues is all done.

In about 12 hours time I expect that oopses from staging/qastaging
will become instantly available. You'll notice this when the ID's
change to a hash.

On the bson front: its a fairly straight forward thing to change it to
rfc822 again if it proves intolerable. I've had no problems finding
things in a local install using grep, because bson doesn't mangle the
string content - it uses length prefixing to serialise it.

If we do find it intolerable, we can switch it back - as long as we
document precisely whats needed to be able to switch forward again :
and we need to as a prelude to moving away from direct FS access to
the oopses, which doesn't scale in any sense of the word.

Rob