[Container-tools] Version incompatibility of Docker client and server - projectatomic/vagrant-adbinfo issue #85

[Suraj Deshmukh]

> Date: Wed, 3 Feb 2016 06:24:40 -0500 (EST)
> From: Shubham Minglani <sminglan at redhat.com>
> To: container-tools at redhat.com
> Subject: [Container-tools] Version incompatibility of Docker client
> 	and server - projectatomic/vagrant-adbinfo issue #85
> Message-ID:
> 	<1625036284.31031562.1454498680940.JavaMail.zimbra at redhat.com>
> Content-Type: text/plain; charset=utf-8
> 
> Hi community,
> 
> I am writing this referring to Issue #85 on projectatomic/vagrant-adbinfo
> raised by Bama yesterday.
> 
> You can read/discuss about it here:
> https://github.com/projectatomic/vagrant-adbinfo/issues/85
> 
> Summary:
> 
> While using vagrant-adbinfo plugin with Docker client of local machine to
> connect to Docker in the Vagrant box, a version mismatch error pops up due
> to difference in the API versions and the API not being backward compatible.
> 
> To make both of them talk, we need to get the versions to match. For the
> same, the following options are being considered:
> 
> - If there is a version mismatch, create another vagrant vm with docker
> client of appropriate version installed and route docker traffic from there.
> - Package the docker client of appropriate version with a slightly modified
> name 'adb-docker' (this could be done through links as well. ie newname link
> pointing to packaged docker client in respective users bin directory) for
> example.
> - Check for version mismatch, and with users permission, upgrade or downgrade
> accordingly.
> 
> Besides these, another approach was proposed today -
> 
> Instead of using Docker CLI client on the base machine, can Remote API [1] or
> one of these Remote API clients [2] be used to access Docker in the Vagrant
> VM? This way upgrading or downgrading Docker on the base machine does not
> have to be worried about, and this will also work across platforms.
> 
> However, in the case of using:
> 
> Remote API [1]:
> - Multiple API versions have to be supported.
> - Effectively, this is like maintaining a new Docker Remote API client.
> 
> Remote API client [2]:
> - If these are well maintained (Docker does not maintain these, except
> docker-py [3]), then each API version does not have to be supported and code
> remains the same.
> - These might not have support for all the Docker CLI client features (even
> docker-py does not support 'everything' which the CLI client does).
> 
> On another note, how about a hybrid approach? When the Remote API client does
> not work (feature not supported or version incompatibility), the Remote API
> can be used to do that thing.
> 
> It would be great if community gives some feedback on this issue, so I'm
> posting it here.
> 
> Please correct me if I'm wrong or talking off-track!
> 
> Regards,
> Shubham Minglani
> 
> P.S. It's my first email here, so open to rectifications :)
> 
> [1] https://docs.docker.com/engine/reference/api/docker_remote_api/
> [2] https://docs.docker.com/engine/reference/api/remote_api_client_libraries/
> [3] https://github.com/docker/docker-py
> 

Hi Shubham,


I think we can use "Software Collections" to solve this problem(on Linux Machines)!
https://www.softwarecollections.org/en/

Thanks

-- 
- Suraj Deshmukh (surajd)
http://deshmukhsuraj.wordpress.com/