Skip to content

Add support for docker 1.8 Mounts #119

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 4 commits into from

Conversation

cybercode
Copy link

This patch uses the current Volumes map instead of creating a new Mounts map. This should make the underlying API changes transparent to docker-gen users.

Rick Frankel added 2 commits September 13, 2015 12:43
       - Set Volumes from Mounts if available
       - Update go-dockerclient dependency
       - Update docker dependency to 1.8.2
@jwilder
Copy link
Collaborator

jwilder commented Sep 22, 2015

I'm not sure if it's better to reuse the Volumes key, create a new Mounts key or do both and deprecate Volumes. Seems like Volumes has been removed in favor of Mounts in new docker versions but I couldn't find any official documentation confirming that.

I'm thinking it would be better to re-use both Volumes and add a new Mounts key to keep some backwards compatibility but also keep the terminology consistent w/ what you see in docker inspect. In future release, Volumes could be removed. Thoughts?

@cybercode
Copy link
Author

On Tue, Sep 22, 2015 at 09:09:36AM -0700, Jason Wilder wrote:

I'm not sure if it's better to reuse the Volumes key, create a new Mounts
key or do both and deprecate Volumes. Seems like Volumes has been removed
in favor of Mounts in new docker versions but I couldn't find any official
documentation confirming that.

The docker people don't seem to believe in semantic versioning, Change notes
or deprecation. The only way to figure out version to version changes is the
API documentation -- which no longer has Volumes in the runtime data
structure, so yes, it's been removed. However, note that Volumes still as
part of the POST api. I'm guessing their thinking is to separate persistent
volumes from mounted host directories.

I'm thinking it would be better to re-use both Volumes and add a new
Mounts key to keep some backwards compatibility but also keep the
terminology consistent w/ what you see in docker inspect. In future
release, Volumes could be removed. Thoughts?

I think the best way to handle the change is in three steps (esp. since
many -- including me -- seem to need a 1.8 compatible version of nginx-proxy):

  1. Reuse the Volumes map, allowing transparent updating to docker 1.8.x
  2. Add the Mounts, using the conventions of underlying map: Source,
    Destination, RW) and deprecating Volumes.
  3. Remove Volumes

If you want to combine 1 & 2, it's ok w/ me (i will push another PR adding
back the Mounts.) Personally, i would do them in separate steps pushing
the current Volumes PR first.

rick

jwilder added a commit that referenced this pull request Jan 2, 2016
Based off of #119
@jwilder
Copy link
Collaborator

jwilder commented Jan 2, 2016

Fixed via #146.

@jwilder jwilder closed this Jan 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants