[jira] [Commented] (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:comment-tabpanel&focusedCommentId=14901395#comment-14901395 ] 

Ignasi Barrera commented on JCLOUDS-1002:
-----------------------------------------

+1 for the first approach. The provider specific options are already coupled to the provider API and is not portable, so being coupled to a concrete Docker API version is something acceptable.

I'd just remove all current options from the DockerTemplateOptions and leave only the Config property. It is not backwards-compatible, but given how simple the current options object is, creating the corresponding Config object is trivial for users upgrading to the latest snapshot.

Anyway, I'd love to hear what [~andrew.kennedy] thinks about this.

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