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:

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