Add expanded mount format to stack deploy#30597
Conversation
91ea532 to
e66d61a
Compare
cli/compose/loader/loader_test.go
Outdated
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
|
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 |
|
We could do a |
e66d61a to
0721f41
Compare
|
Rebased |
cli/compose/schema/schema.go
Outdated
There was a problem hiding this comment.
Can we make these strings constant values?
0721f41 to
4111153
Compare
|
Spoke with Daniel since I was having some issues trying to get this going. From a functionality POV, just have a couple of issues:
|
I believe it's still possible for all fields (it even works with the old short syntax, see #30770) . For data:
external:
name: '{{ .Template }}' |
617e237 to
a1bbb2f
Compare
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>
|
ping |
vdemeester
left a comment
There was a problem hiding this comment.
Should we add a mount alias though ? 👼
|
When it's supported by the CLI sure, but I think that's not required to merge this. We can add it later. |
|
@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? |
|
Opened docker/docs#2283 |
|
@dnephin what cli? Service is --mount as is. |
|
True. The compose file fields are named after the |
|
@dnephin is there any reason we can't do a major bump of compose format for 17.04? |
|
You mean make it v4? There are no backwards incompatible changes, or any significantly large changes, so v4 would not be appropriate. |
|
@dnephin I meant so we can add |
|
Ok, lets leave any |
|
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. |
…to-stack-deploy Add expanded mount format to stack deploy
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