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

["Ignasi Barrera (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/JCLOUDS-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ignasi Barrera resolved JCLOUDS-1002.
-------------------------------------
       Resolution: Fixed
    Fix Version/s: 2.0.0

> 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
>              Labels: docker
>             Fix For: 2.0.0
>
>
> 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)