Hi there
I'm trying to understand how the job metrics configuration works. Reading
through various examples, it looks like it works together with the dynamic
destination support.
First on the dynamic destination support, this works, as I understand it,
by importing modules (files ending in .py) from the directory set as the
rules_module, where rules_module is a parameter for the dynamic job plugin.
As in this snipped from the usegalaxy configuration:
<plugin id="dynamic" type="runner">
<!-- These live in the virtualenv -->
<param id="rules_module">usegalaxy.jobs.rules</param>
</plugin>
So import usegalaxy.jobs.rules, find where this resolves to as a directory,
find all .py files in that directory. If rules_module is not specified, the
default is galaxy.jobs.rules (under galaxy/lib).
So these .py files are imported and within them are functions that are used
in dynamic destinations (those with runner="dynamic") and in turn tools are
directed to use these destinations.
Now the job metrics configuration supplies both a user interface and then a
set of keys that are made accessible to dynamic runners as key value pairs
on the job.parameters attribute (passed in as the third argument, i.e.
job). Specifically the job metrics configuration exists under a key
'__job_resource'.
Is this all correct? Is there a more straightforward way of moving from job
resource specification to job configuration than this?
Thanks,
Peter
___________________________________________________________
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
https://lists.galaxyproject.org/
To search Galaxy mailing lists use the unified search at:
http://galaxyproject.org/search/mailinglists/
