Mount volumes before copying into a container #24655
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mheon The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
|
Still needs a test, putting this up so I can have some folks look at it. |
libpod/container_copy_common.go
Outdated
| defer func() { | ||
| vol.lock.Lock() | ||
| if err := vol.unmount(false); err != nil { | ||
| logrus.Errorf("Unmounting volume %s after container %s copy: %v", vol.Name(), c.ID(), err) | ||
| } | ||
| vol.lock.Unlock() | ||
| }() |
There was a problem hiding this comment.
This does not look right, this function here isn't doing any work it is returning another function so defer runs before the copy, you must add that to unmount() in the if else case above.
|
/hold Requires extensive rework, DO NOT MERGE until I repush |
openshift-ci
bot
added
the
do-not-merge/hold
This solves several problems with copying into volumes on a container that is not running. The first, and most obvious, is that we were previously entirely unable to copy into a volume that required mounting - like image volumes, volume plugins, and volumes that specified mount options. The second is that this fixed several permissions and content issues with a fresh volume and a container that has not been run before. A copy-up will not have occurred, so permissions on the volume root will not have been set and content will not have been copied into the volume. If the container is running, this is very low cost - we maintain a mount counter for named volumes, so it's just an increment in the DB if the volume actually needs mounting, and a no-op if it doesn't. Unfortunately, we also have to fix permissions, and that is rather more complicated. We need the final OCI spec (as we need final UID/GID user namespace mappings), we need to do the chown after the copy has occurred, and we need to do some ugly manual changes to volume copyup/chown fields to make sure the copy sticks. It's really ugly, but necessary to reach full Docker compatibility. Signed-off-by: Matthew Heon <[email protected]>
mheon
force-pushed
the
fix_volume_perms_cp
branch
from
39a7445
to
a34abed
Compare
|
/hold cancel |
openshift-ci
bot
removed
the
do-not-merge/hold
|
Cockpit tests failed for commit a34abed. @martinpitt, @jelly, @mvollmer please check. |
This solves several problems with copying into volumes on a container that is not running.
The first, and most obvious, is that we were previously entirely unable to copy into a volume that required mounting - like image volumes, volume plugins, and volumes that specified mount options.
The second is that this fixed several permissions and content issues with a fresh volume and a container that has not been run before. A copy-up will not have occurred, so permissions on the volume root will not have been set and content will not have been copied into the volume.
If the container is running, this is very low cost - we maintain a mount counter for named volumes, so it's just an increment in the DB if the volume actually needs mounting, and a no-op if it doesn't.
Does this PR introduce a user-facing change?