On Wed, Oct 19, 2011 at 3:33 AM, Robert Collins <robe...@robertcollins.net> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
