First, John, that "$output_dataset.creating_job.history.id" looks great!
Ok, Dannon, I see various merits of stateless design - always providing server
processes with the entire input array (files, params) in which no server state
memory is referenced for a given user/agent task (aside from use
Thanks to all of you for the comments and code help. John's example is
grabbing the target history for the output, which is actually perfect for
us. i get that 'current history' doesnt really mean anything, and the
target history for the output file is a far more reliable option. I
simplified th
On Tue, May 5, 2015 at 3:40 PM, Ben Bimber wrote:
> Thanks to all of you for the comments and code help. John's example is
> grabbing the target history for the output, which is actually perfect for
> us. i get that 'current history' doesnt really mean anything, and the
> target history for the
Galaxy's API goal is to be intentionally stateless, and methods that
operate on a history accept that as a parameter and don't recognize the
notion of 'current'. State like that is to be maintained in the client,
whatever that is -- whether a webpage, cron job, etc. I think this
approach is proba
I had an epiphany - I think the follow idioms will let you get the
current history id and current history name. It is more robust than
the code file trick because it will also work with direct API calls
where there is no "current history" (doesn't require use of trans).
https://gist.github.com/jmc
P.s. I tried using BioBlend and(or) the Galaxy API to get a given user's
current history but found there was no way to do so.
Seems like there is occasionally a tension between "plaform by design" (reduced
instruction set, occasionally with security in mind, or dev resource
limitations) and "
Yes, stooping to using in the workaround. What I remember is that it
was only via the dynamic_options() call that I had access to __trans__
variable. If someone on dev knows of another way to get __trans__ stuff via
cheeta directly in the XML definition file that would be great.
Cheers,
Dam
Hi Damion,
Possibly a dumb question, but I thought I'd ask: if i understand your
example, you're basically end-running galaxy due to the fact that for
dynamic options you can execute code. When this is called, galaxy passes
in an object that lets you access the current history ID.
In other conte
On Tue, May 5, 2015 at 10:24 AM, David Trudgian
wrote:
> I also installed an up-to-date python 2.7.x for Galaxy using pyenv but this
> shouldn't be necessary - Galaxy should work fine on python 2.6.
I would strongly suggest using the latest Python 2.7 for any new
Galaxy deployment. Though there
I wanted to add that I have a niche justification for having UUID available in
tool interface. My tool needed to scan user's current history in order to
determine if user already had generated relevant datasets. If they didn't
exist, my tool triggered the generation of them, and loaded them in
Hi Carlos,
I previously used Galaxy with a GridEngine cluster. Having GridEngine is no
more complex than having SLURM.
R.E. you other email, recording cluster usage for labs' galaxy jobs, that
requires the 'running jobs as real user' setup...
https://wiki.galaxyproject.org/Admin/Config/Perform
About
1. find UUID of current history in tool XML wrapper? (Ben Bimber)
2. Re: find UUID of current history in tool XML wrapper?
(John Chilton)
I think this will work for you, I've simplified the code. I was able to do
this somewhat circuitously (=bonfire of time) for my upcoming Ver
Thank you Peter, I am now getting a clear idea on how our deployment will
go. Yes, I followed up with David and he provided additional insights
into his deployment. What a great virtual team !!! Thank you.
Carlos
On 5/5/15, 4:12 AM, "Peter Cock" wrote:
>Hi Carlos,
>
>We're running Galaxy on
Thank you for the feedback Zuzanna,
Would you have documentation on scripts your updated or any lessons
learned during your deployment? I¹m trying to get as much feedback as
possible to hit the ground running when the cluster is delivered in our
facility.
One more question, do you use SGI or SLU
Hi Carlos,
Our Galaxy is running on RedHat 6.6 on our cluster - which is basically
identical to CentOS 6.6. Per Peter's email we haven't had any big issues with
Galaxy on CentOS 6.x.
You are likely to want to use the postgresql packages from www.postrgresql.org,
not the out-of-date versions th
Dnia 2015-05-04, pon o godzinie 11:48 +0200, Zuzanna K. Filutowska
pisze:
> Dear All,
>
> is there any option to not remove files that has been imported to Galaxy
> from FTP directory and to not remove files that haven't been imported
> since 3 days?
I would be grateful if someone from developers
Dnia 2015-05-05, wto o godzinie 01:51 +, Carlos Lijeron pisze:
> Hello everyone,
>
>
>
> We are soon acquiring our cluster which has CentOS on the master node
> along with Bright Cluster Manager and workload manager. We are
> wondering if there is a guideline on how to install and support
Hi Carlos,
We're running Galaxy on CentOS 6.6, so that in itself shouldn't be a
problem. Most of the effort was sorting out shared storage with the
cluster, which in our case is managed with SGE (fairly commonly
used with Galaxy).
In reply to your thread last month David Trudgian said he was usin
Hi Folks
I am trying to add a custom genome so that all users can choose it as
reference in trackster (and others).
When I go to " Show loaded, system-installed builds
" the build is listed, but it does not appear in
the trackster reference build drop-down list.
I have provided the fasta
19 matches
Mail list logo
