[jira] [Created] (JCLOUDS-1002) Docker: Make the whole container Config object configurable by user

["Josef Cacek (JIRA)" <ji...@apache.org>]

Josef Cacek created JCLOUDS-1002:
------------------------------------

             Summary: Docker: Make the whole container Config object configurable by user
                 Key: JCLOUDS-1002
                 URL: https://issues.apache.org/jira/browse/JCLOUDS-1002
             Project: jclouds
          Issue Type: New Feature
          Components: jclouds-labs
    Affects Versions: 1.9.1
            Reporter: Josef Cacek


It would be nice if the {{TemplateOptions}} for Docker provide full access to  {{org.jclouds.docker.domain.Config}}.

There could be for instance the second option class named
{{org.jclouds.docker.compute.options.DockerConfigTemplateOptions}} which holds instance of the {{Config.Builder}}. Then change the {{DockerComputeServiceAdapter}} implementation to be able handle both options class types.

Benefits of this approach:
* user has full control over the container configuration
* it can avoid problems which can be currently seen in the {{DockerComputeServiceAdapter}} - e.g. only TCP port mappings, Maps-to-Lists mappings, null-values vs empty Lists/Maps, ...

Caveeats:
* The config object is related to Docker REST API. The changes in there could break the JClouds docker-provider user API (or add complexity to this DTO). How to solve it?
** Use the new TemplateOptions only for advanced cases and make the compatibility an user responsibility - they must keep the code synchornized with the Docker API version used in the JClouds version
** or Don't provide the {{Config.Builder}} from {{DockerConfigTemplateOptions}} directly. Introduce new methods which will only call appropriate method from the builder. This approach doesn't cleanly cover {{HostConfig}}

I personally prefer the first solution - i.e. provide direct access to the {{Config.Builder}} instance.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)