launchpad-dev team mailing list archive

[Stuart Bishop <stuart.bishop@xxxxxxxxxxxxx>]

On Fri, Oct 1, 2010 at 4:58 PM, Danilo Šegan <danilo@xxxxxxxxxxxxx> wrote:
> У пет, 01. 10 2010. у 11:46 +0700, Stuart Bishop пише:
>> On Thu, Sep 30, 2010 at 10:41 PM, Danilo Šegan <danilo@xxxxxxxxxxxxx> wrote:
>> > Cool stuff Stuart!
>> >
>> > У сре, 29. 09 2010. у 22:19 +0700, Stuart Bishop пише:
>> >
>> >> Cronscripts now generate OOPS reports for WARNING and above log
>> >> messages. Other scripts do not (they could, but it didn't seem to make
>> >> much sense).
>> >
>> > How are cronscripts which already produce OOPSes going to be affected?
>> > (Eg. rosetta-poimport script)
>>
>> If you are emitting WARNING, ERROR or CRITICAL messages as well as
>> generating the OOPS, your going to end up with two OOPSes.
>>
>> We should pull out the OOPS reporting code from these scripts, and
>> improve the common OOPS reporting code if necessary.
>
> Actually, the script that I am interested in emits OOPS for failures
> inside the loop, but lets the outer loop continue (i.e. we used to
> frequently get failures on a single import, but that should not stop
> other imports from happening: today we get only seldom failures in
> there).
>
> What would be the best thing to do in such a case?  Just stop emitting
> WARNINGs and ERRORs?

Keep emitting the WARNING and ERRORs and don't emit the OOPS - it will
be done for you.

What I don't know if the common OOPS reporting is rich enough for your
needs - at the moment you just get the error message and a traceback
if you used logger.exception(error_message). We might have to extend
the OopsHandler.

If it is unsuitable, it is easy enough to add an attribute to
LaunchpadCronScript that stops the LaunchpadCronScript.__init__ from
installing the OopsHandler. But I'd rather the common facility was
made good enough rather than reinventing the wheel whenever we have
special needs.


-- 
Stuart Bishop <stuart@xxxxxxxxxxxxxxxx>
http://www.stuartbishop.net/