Hi all,
I've been running into some sporadic errors on our Cluster while
using the latest development Galaxy, and the error handling has
made this quite difficult to diagnose.
For a user perspective, the jobs seem to run, get submitted to
the cluster, and finish, and the data looks OK via the
Dear all,
Is there a plan to record the return code (error level) in the
Galaxy Job history, along with the stdout and stderr strings?
I would find this very useful - especially for situations where
a job is killed (e.g. by the OS) and there is no indication of
why it died (stderr is empty).
Somewhat related, can I make a feature request that in the job attribute
editor screen (i.e. what you get when you click the pencil icon in the top
right corner of a history item), you can manually change the state of a
job from failed (which means you can't use the output in any subsequent
Hello Galaxy-team!
I installed recently two differents versions of Galaxy and I would like to
use the same database for the two instances without loosing data
(histories, workflows etc..).
Thank you in advance
Amine
___
Please keep all
If the two different Galaxy instances are different *versions* of
Galaxy, this is unlikely to work out well.
-- jt
On Fri, Sep 21, 2012 at 11:59 AM, Chebbi Mohamed Amine
chebbimam...@gmail.com wrote:
Hello Galaxy-team!
I installed recently two differents versions of Galaxy and I would like
Definitely not. And please keep replies on the list.
-- jt
On Fri, Sep 21, 2012 at 1:50 PM, Chebbi Mohamed Amine
chebbimam...@gmail.com wrote:
Yes the two instances are of two different versions. So if I understand well
there is no mean to do it like this ?
Thanks
2012/9/21 James Taylor
Thanks, Peter! Those are good suggestions. I'll look into it soon.
-Scott
- Original Message -
Hi all,
I've been running into some sporadic errors on our Cluster while
using the latest development Galaxy, and the error handling has
made this quite difficult to diagnose.
For a
Just to be clear, whenever a tool's stdio rules are triggered
there should be messages prepended to stdout and/or stderr.
If a tool defines a stdio regular expression and the regular
expression matches on stdout, a message should be prepended to
stdout. However, these will be empty if tools
Perhaps I missed it but why 'Definitely not' ?
If storage is a limiting factor/constraint, then may be worth attempting
... ?
Promita
On Fri, Sep 21, 2012 at 3:13 PM, James Taylor ja...@jamestaylor.org wrote:
Definitely not. And please keep replies on the list.
-- jt
On Fri, Sep 21, 2012
On Friday, September 21, 2012, Scott McManus wrote:
Just to be clear, whenever a tool's stdio rules are triggered
there should be messages prepended to stdout and/or stderr.
If a tool defines a stdio regular expression and the regular
expression matches on stdout, a message should be
Maybe a better question is why you would want two separate versions
of galaxy running to begin with. There could be another way to solve
your problem.
-Scott
- Original Message -
The main problem with different versions of galaxy is that the
database schema that they expect (as
Yes,as long as this happens soon, it is a safe assumption that almost
all existing tools ignored the return code (because they couldn't use
it till recently).
Or allow the error code field to be null in the database (shown as blank
or not available in the web interface).
Peter
On Friday,
So in this case how is it possible to migrate data form the old database
to the new one. In fact i have two different versions of Galaxy installed
in my machine and I don't want to loose data like histories that I creted
in the old version one.
Thanks for help
Amine
2012/9/21 Dannon Baker
I've run into this issue again, and I'm having a hard time working
around it. However, I have confirmed that at least some updates to a
tool in the tool shed will invalidate previously valid revisions and
thus prevent users from installing or updating the tool at all.
For example, push
OK, I was able to get a new version installed. It seems there are two
issues:
1) New revisions with the same version ionvalidate previous
revisions. This means that Galaxy servers with the old, and now
invalid, revisions are not able to update the tool (nor install it again).
2) Pushes
Good - after taking a step back I thought it seemed better to leave everything
null
rather than guess at an exit code. Does anyone have any objections to adding an
exit code column with null values for previously-executed jobs?
-Scott
- Original Message -
Or allow the error code
16 matches
Mail list logo
