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. Couple this with outputs_to_working_directory to allow Galaxy jobs to write to only a very small portion of the filesystem, couple with the LWR and staging to restrict reading to small portion of the file system as well. See examples in job_conf.xml.sample_advanced for more details.

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).

Much is left to be discussed and worked through - where to pull images from, how to reference images, tool shed integration, multi-core tools, 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.