Add an 'error_msg' table to the schema

[Muharem Hrnjadovic]

It needs a foreign key to an 'oq_job' row and a brief and detailed VARCHAR column respectively.

[Muharem Hrnjadovic (al-maisan)]

Also, add a 'supervisor_pid' column to the 'oq_job' table.

[Lars Butler (lars-butler)]

I'm thinking of implementing this table as 'log_msg', rather than just 'error_msg'. Not all log messages are 'errors' and we may want to capture more info than just errors. Thoughts?

[Gabriele Favalessa (favalex)]

If this table is intended to store log messages (fact that is not clear to me from the bug description) maybe a timestamp and a level are also appropriate.

[Lars Butler (lars-butler)]

Good idea. I believe this table is intended as persistent log storage. Even if we were just capturing errors (and not 'info' level messages), I think it is appropriate anyway to capture the level and timestamp.

[Lars Butler (lars-butler)]

Since the job supervisor hasn't acutally been built yet, I'm going to add the 'supervisor_pid' requirement [1] to the 'Implement job supervisor' bug [2].

[1] https://bugs.launchpad.net/openquake/+bug/812698/comments/1
[2] https://bugs.launchpad.net/openquake/+bug/825325

[Anton Gritsay (angri)]

I wouldn't store all log messages in the DB, especially in RDB. Why not make it simpler and just add "error_msg" column to jobs table?

[Lars Butler (lars-butler)]

Why wouldn't you store them in an RDB?

We want to store multiple messages per job; 1 error message per job record does not satisfy our requirements.

[Anton Gritsay (angri)]

> Why wouldn't you store them in an RDB?

Doesn't storing all log records in database mean cluttering it unnecessarily?

> We want to store multiple messages per job; 1 error message per job record does not satisfy our requirements.

If all we really need to store is the message why job was not able to complete ("error_msg") it could be only one per job, isn't it?

[Lars Butler (lars-butler)]

> Doesn't storing all log records in database mean cluttering it unnecessarily?

No. Not if you want to be able to access your log messages easily and mine them for information (and we do).

> If all we really need to store is the message why job was not able to complete ("error_msg") it could be only one per job, isn't it?

There can be multiple errors for a job. For instance, two or more worker nodes could report errors before the system has a chance to halt the job. We want to know about those errors (not just one).

[Lars Butler (lars-butler)]

Okay, so I completely misunderstood the purpose of this bug.

The 'error_msg' table will be used to store a single message which details why a job failed. This will displayed to user in the case of a failure. The user will initially see the 'brief' error, and if they wish they can view the 'detailed' error for the full message.

[Lars Butler (lars-butler)]

Pull request: https://github.com/gem/openquake/pull/414

[Muharem Hrnjadovic (al-maisan)]

On 08/16/2011 04:26 PM, Lars Butler wrote:
> Okay, so I completely misunderstood the purpose of this bug.
>
> The 'error_msg' table will be used to store a single message which
> details why a job failed. This will displayed to user in the case of a
> failure. The user will initially see the 'brief' error, and if they wish
> they can view the 'detailed' error for the full message.
A single error message might be a bit restrictive. I guess the job
supervisor would want to store the first N of the error messages it gets
to see.
What might be a good choice for N? I don't know .. maybe it is N=1 after
all.