X Tutup
Skip to content

Add expanded mount format to stack deploy#30597

Merged
justincormack merged 4 commits intomoby:masterfrom
dnephin:add-expanded-mount-format-to-stack-deploy
Mar 14, 2017
Merged

Add expanded mount format to stack deploy#30597
justincormack merged 4 commits intomoby:masterfrom
dnephin:add-expanded-mount-format-to-stack-deploy

Conversation

@dnephin
Copy link
Member

@dnephin dnephin commented Jan 31, 2017

Fixes #29193
Fixes #31224
Also (should) fix some windows support for volumes

I've added this to Compose format v3.1 for now, but it might be more appropriate for a v3.2, depending on when it gets merged and where it gets cherry-picked.

@cpuguy83 I'd appreciate your review of 3c74323d94491571e8667ba0a4b2cca9911b4dc0. It adds a client-side parser for the old volume spec. As far as I know this is the first time we're attempting to fully parse the spec on the client (without being aware of the engine platform). It assumes no knowledge of the platform, so windows and linux container paths are both supported on all clients.

@shin- we will probably need to implement this on the python side as well. It should be a smaller change. I think we'll only need to copy the schema and implement something like 3c74323d94491571e8667ba0a4b2cca9911b4dc0

cc @vdemeester

Copy link
Member

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SGTM 👼
I wonder how using volume fits with ongoing discussion on #28527 (volumes, mounts ?).

/cc @icecrime @stevvooe

@dnephin dnephin force-pushed the add-expanded-mount-format-to-stack-deploy branch from 91ea532 to e66d61a Compare February 7, 2017 18:09
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't these be called mounts? It is very confusing to have a volume declaration here then a volume declaration at the top level. This contributes to confusion. Not that this section will also handle binds, so calling it volumes is inaccurate.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but it's also a breaking change, so not something we can change in the v3.1 format. We missed our chance with v3, so we can queue it up for v4 I guess (depending on the outcome of the docker run flag change).

@stevvooe
Copy link
Contributor

stevvooe commented Feb 7, 2017

The format looks good, in general. I would really prefer that we call it mounts, or at least have that as an alias. It is very weird to have volumes, then type: volume. It is also problematic to mix binds, volume, tmpfs, (and soon image mounts!) into volume. We should focus the term volume around the orchestratable object.

@dnephin
Copy link
Member Author

dnephin commented Feb 7, 2017

We could do a mount alias

@dnephin
Copy link
Member Author

dnephin commented Feb 16, 2017

Rebased

Copy link
Member

@AkihiroSuda AkihiroSuda Feb 28, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make these strings constant values?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure

@justincormack
Copy link
Contributor

cc @cpuguy83 @jhowardmsft

@cpuguy83
Copy link
Member

cpuguy83 commented Mar 3, 2017

Spoke with Daniel since I was having some issues trying to get this going. From a functionality POV, just have a couple of issues:

  • When "driver" is not defined on the volume, "driver_opts" are not passed through
  • The --mount cli supports templating everything about the mount spec, including Source which allows for some really powerful use-cases... this is kind of lost here afaict.

@dnephin
Copy link
Member Author

dnephin commented Mar 3, 2017

The --mount cli supports templating everything about the mount spec, including Source which allows for some really powerful use-cases... this is kind of lost here afaict.

I believe it's still possible for all fields (it even works with the old short syntax, see #30770) . For source it requires that you use an external volume, because the source name in the service has to be a reference to a volume definition. The volume definition can use a template:

data:
  external:
    name: '{{ .Template }}'

@dnephin dnephin force-pushed the add-expanded-mount-format-to-stack-deploy branch 2 times, most recently from 617e237 to a1bbb2f Compare March 6, 2017 16:45
dnephin added 4 commits March 6, 2017 11:45
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Add a test for loading expanded mount format.

Signed-off-by: Daniel Nephin <dnephin@docker.com>
Signed-off-by: Daniel Nephin <dnephin@docker.com>
@dnephin
Copy link
Member Author

dnephin commented Mar 8, 2017

ping

Copy link
Member

@cpuguy83 cpuguy83 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Member

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add a mount alias though ? 👼

@dnephin
Copy link
Member Author

dnephin commented Mar 10, 2017

When it's supported by the CLI sure, but I think that's not required to merge this. We can add it later.

Copy link
Member

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds fair.
LGTM 🦁

@thaJeztah
Copy link
Member

@dnephin can you open a pull request in the https://github.com/docker/docker.github.io repository for the syntax changes in the docker-compose file?

@dnephin
Copy link
Member Author

dnephin commented Mar 13, 2017

Opened docker/docs#2283

@dnephin dnephin mentioned this pull request Mar 13, 2017
@cpuguy83
Copy link
Member

@dnephin what cli? Service is --mount as is.

@dnephin
Copy link
Member Author

dnephin commented Mar 14, 2017

True. The compose file fields are named after the docker run cli. Either way we can't drop volumes as the key in a minor version, so we can either decide to add an alias of mounts during code freeze, or we can decide to worry about it for the next version.

@justincormack
Copy link
Contributor

@dnephin is there any reason we can't do a major bump of compose format for 17.04?

@dnephin
Copy link
Member Author

dnephin commented Mar 14, 2017

You mean make it v4? There are no backwards incompatible changes, or any significantly large changes, so v4 would not be appropriate.

@justincormack
Copy link
Contributor

@dnephin I meant so we can add mounts which you said was not suitable for a minor bump.

@justincormack
Copy link
Contributor

Ok, lets leave any mounts change for another PR that bumps the API.

@justincormack justincormack merged commit 49376cd into moby:master Mar 14, 2017
@GordonTheTurtle GordonTheTurtle added this to the 17.04.0 milestone Mar 14, 2017
@dnephin dnephin deleted the add-expanded-mount-format-to-stack-deploy branch March 14, 2017 17:58
@dnephin
Copy link
Member Author

dnephin commented Mar 14, 2017

I see what you mean. I think we'll probably want to batch up a few other breaking changes all at once before making a v4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Compose file parsing can't parse Windows paths Support expanded ports and mount format in the the compose v3 format

8 participants

X Tutup