Skip to content
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

Fix volumes-from/bind-mounts passed in on start #9631

Merged

Conversation

cpuguy83
Copy link
Member

Fixes #9628

@cpuguy83 cpuguy83 force-pushed the 9628_fix_volumes_hostconfig_on_start branch 2 times, most recently from 7f47e7d to 432bd17 Compare December 12, 2014 16:10
@cpuguy83
Copy link
Member Author

ping @jfrazelle @crosbymichael
This is the issue @proppy was having yesterday on 1.4

if path, exists := m.container.Volumes[m.MountToPath]; exists {
// If this is a bind-mount/volumes-from, maybe it was passed in at start instead of create
// We need to make sure bind-mounts/volumes-from passed on start can over-shadow non-binds
// FIXME: This is a hack until HostConfig on container start is totally unsupported
Copy link
Contributor

Choose a reason for hiding this comment

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

You cannot say this and we need to revert the docs that say that this is deprecated as this is not the case and will not be deprecated. For the longest time this has been the only way of passing binds and volumes and so many third party clients use this as there was no other way.

@cpuguy83 cpuguy83 force-pushed the 9628_fix_volumes_hostconfig_on_start branch 2 times, most recently from 1665254 to b9ad32f Compare December 12, 2014 20:14
@cpuguy83
Copy link
Member Author

Fixed that wording.

@crosbymichael
Copy link
Contributor

Thanks, I'm doing some testing now

@crosbymichael crosbymichael added this to the 1.4.1 milestone Dec 12, 2014
@@ -61,12 +61,6 @@ You can set the new container's MAC address explicitly.
**New!**
Volumes are now initialized when the container is created.
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe makes sense to specify somewhere that this volumes will be shadowed by start options.

Copy link
Contributor

Choose a reason for hiding this comment

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

+1

Copy link
Contributor

Choose a reason for hiding this comment

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

Can you please at least ping docs when stuff like this comes up? I have no way of discovering issues like this in a timely manner otherwise.

if !m.volume.IsBindMount && m.from == nil {
return nil
}
if m.volume.Path == path {
Copy link
Contributor

Choose a reason for hiding this comment

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

What does this line mean?

Copy link
Member Author

Choose a reason for hiding this comment

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

This is checking if the path of the passed in volume is the same as the path in container.Volumes.

Copy link
Contributor

Choose a reason for hiding this comment

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

But why are you checking for this and returning?

Copy link
Member Author

Choose a reason for hiding this comment

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

Because if it's the same then we don't need to do anything.
Same path means the same volume as there is only 1 volume object per path.

@ibuildthecloud
Copy link
Contributor

FYI, I tested this and it has fixed my issues I've seen with 1.4

@crosbymichael
Copy link
Contributor

@ibuildthecloud thanks for testing

}

if err := container.applyVolumesFrom(); err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

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

Add a comment explaining that this will reset the volumesfrom hostconfig each time and that this is needed in order for start to override what was set in create.

@cpuguy83 cpuguy83 force-pushed the 9628_fix_volumes_hostconfig_on_start branch from b9ad32f to 01becdc Compare December 15, 2014 20:21
@@ -61,12 +61,6 @@ You can set the new container's MAC address explicitly.
**New!**
Volumes are now initialized when the container is created.

`POST /containers/(id)/start`
Copy link
Contributor

Choose a reason for hiding this comment

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

In the PR's first comment, it'd be great to add a reference to the PR that is being partially reverted. (#8683)

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

Copy link
Contributor

Choose a reason for hiding this comment

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

@cpuguy83 I don't see it

Fixes moby#9628
Slightly reverts moby#8683, HostConfig on start is _not_ deprecated.

Signed-off-by: Brian Goff <cpuguy83@gmail.com>
@cpuguy83 cpuguy83 force-pushed the 9628_fix_volumes_hostconfig_on_start branch from 01becdc to d44c9f9 Compare December 15, 2014 21:52
@cpuguy83
Copy link
Member Author

Updated.
Added new test to make sure that VolumesFrom has priorty over anything else, as is the case with the corresponding CLI test(TestRunApplyVolumesFromBeforeVolumes)

@cpuguy83
Copy link
Member Author

*new test and fixed an issue where that wasn't the case.

@crosbymichael
Copy link
Contributor

@jfrazelle @LK4D4 I removed your LGTM since the code changed in the last revision

@jessfraz
Copy link
Contributor

@ibuildthecloud if you want to retest as well that would be awesome, if not no biggie :)

@LK4D4
Copy link
Contributor

LK4D4 commented Dec 15, 2014

I retested it with docker-py and fig. All is okay. I don't see obvious bugs also(as always 😆 )

@jessfraz
Copy link
Contributor

lftm

@unclejack
Copy link
Contributor

Would it be too much to ask for a test in docker_api in integration-cli?

@LK4D4
Copy link
Contributor

LK4D4 commented Dec 15, 2014

@unclejack I see that there are three tests in this PR.

@crosbymichael
Copy link
Contributor

I'm also adding the entire docker-py integration tests for the lib in #9676 for API tests not owned by us.

@crosbymichael
Copy link
Contributor

LGTM

@tiborvass
Copy link
Contributor

LGTM, although the code is very complicated to read :(

crosbymichael added a commit that referenced this pull request Dec 15, 2014
…_start

Fix volumes-from/bind-mounts passed in on start
@crosbymichael crosbymichael merged commit 24d03b8 into moby:master Dec 15, 2014
@cpuguy83 cpuguy83 deleted the 9628_fix_volumes_hostconfig_on_start branch September 20, 2017 16:56
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.

issues with api bind/volumesfrom on start
8 participants