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)
