Outline of Docker-based dependency resolution.

Works with all stock job runners including LWR.

Supports file system isolation allowing deployer to determine what paths are exposed to container and optionally allowing these to be read-only. This can be overidden or extended but defaults are provided that attempt to guess what should be read-only and what should be writable based on Galaxy's configuration and the job destination (e.g. if outputs_to_working_directory is container is allowed to write to much less and if using LWR container is allowed to read and write to much less). Lots of details and discussion in job_conf.xml.sample_advanced.

Currently tools must annotate what container can be used to run the tool. Left in hooks for a more expansive approach where containers could be linked requirements and resolved that way (this is not implemented at all but the class ContainerRegistry is instantiated, passed the list of requirements, and given the chance to return a list of potential containers if someone wants to write this).

Metadata is set outside the container - so the container itself only needs to supply the underlying application and doesn't need to be configured with Galaxy for instance. Likewise - traditionl tool_dependency_dir based resolution is disabled when job is run in a container - it is assumed the container will supply these dependencies (for now).

GALAXY_SLOTS is passed into container at runtime and will be available.

Much is left to be discussed and worked through - where to pull images from, how to reference images, tool shed integration, etc.... This is meant more as a proof of concept and demonstration of how I think the key pieces should fit within existing Galaxy abstractions than a final, polished product.