Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Conversation

rhvgoyal
Copy link
Contributor

Until and unless user has specified a propagation property for volume, they
should default to "rprivate" and it should be passed to runc.

We can't make it conditional on HasPropagation(). GetPropagation() returns
default of rprivate if noting was passed in by user.

If we don't pass "rprivate" to runc, then bind mount could be shared even
if user did not ask for it. For example, mount two volumes in a container.
One is "shared" while other's propagation is not specified by caller. If
both volume has same source mount point of "shared", then second volume
will also be shared inside container (instead of being private).

Signed-off-by: Vivek Goyal vgoyal@redhat.com

- What I did

- How I did it

- How to verify it

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

@rhvgoyal
Copy link
Contributor Author

I think following commit introduce this change. @cpuguy83 can you please have a look.

From fc7b904 Mon Sep 17 00:00:00 2001
From: Brian Goff cpuguy83@gmail.com
Date: Tue, 26 Apr 2016 14:25:35 -0400
Subject: [PATCH 1/1] Add new HostConfig field, Mounts.

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.

Thanks for the ping, nice catch.

volume/volume.go Outdated
Copy link
Member

Choose a reason for hiding this comment

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

We should not change the spec itself since this is what the user defined.
Instead we should update the returned mountpoint here: https://github.com/moby/moby/blob/master/volume/volume.go#L314

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, will do.

Copy link
Member

Choose a reason for hiding this comment

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

This might break some tests.

Copy link
Member

Choose a reason for hiding this comment

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

And if not, we should have a unit test to make sure the default is set :)

@rhvgoyal
Copy link
Contributor Author

Pushed new patch. let me see what test cases are broken and will fix them.

volume/volume.go Outdated
Copy link
Member

Choose a reason for hiding this comment

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

I think we have a DefaultMountPropagation const that would be a little nicer here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok, will use that.

Until and unless user has specified a propagation property for volume, they
should default to "rprivate" and it should be passed to runc.

We can't make it conditional on HasPropagation(). GetPropagation() returns
default of rprivate if noting was passed in by user.

If we don't pass "rprivate" to runc, then bind mount could be shared even
if user did not ask for it. For example, mount two volumes in a container.
One is "shared" while other's propagation is not specified by caller. If
both volume has same source mount point of "shared", then second volume
will also be shared inside container (instead of being private).

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
@rhvgoyal rhvgoyal force-pushed the volume-propagation branch from d43ecde to af8a143 Compare April 26, 2017 20:28
@rhvgoyal
Copy link
Contributor Author

@cpuguy83 PTAL. Failure of janky and experimental is not due to my PR. I have fixed unit tests and they will also ensure that default propagation mode is passed properly.

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

@rhvgoyal
Copy link
Contributor Author

Can this PR be merged now. It has passed all tests and has one LGTM.

@justincormack
Copy link
Contributor

It has mine too, but I accidentally lost my ability to merge in the move...

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.

5 participants

Morty Proxy This is a proxified and sanitized view of the page, visit original site.