plugins: container-rootfs-relative paths#26398
Conversation
de699b3 to
895ef95
Compare
plugin/manager.go
Outdated
There was a problem hiding this comment.
@anusha-ragunathan @vieux I changed this to accommodate legacy plugins that have hardcoded /run/docker/plugins already. I had initially chosen /run/docker because it was shorter. To be clear: this is the path inside the container where we expect the socket to be.
There was a problem hiding this comment.
Works for me. It reduces the code change required by the legacy plugins to move to pluginv2.
There was a problem hiding this comment.
@tiborvass : you dont need to change this for plugins. This is the host directory that gets bind mounted to the plugin. The plugin run time path is defaultPluginRuntimeDestination which is already set to /run/docker/plugins https://github.com/docker/docker/blob/fa7c1a68a68ffb7c6851c59d2c0b41091b9d6e5e/plugin/v2/plugin.go#L29
We could change runRoot back to /run/docker/plugins to indicate that the directories that get created under there are plugins related.
There was a problem hiding this comment.
For a separate PR, but this should not be hard-coded to /run/docker but instead use the daemon exec root
There was a problem hiding this comment.
The reason to hard code is that, this holds the plugin socket. There's a socket path limitation on Linux to 108 bytes. The daemon exec root doesnt have any socket and is not bound by this limitation. So we have to choose a path that always works.
895ef95 to
cc0760a
Compare
plugin/v2/plugin.go
Outdated
There was a problem hiding this comment.
p.Rootfs can also be used in https://github.com/docker/docker/blob/master/plugin/backend.go#L132
|
Lets keep this PR specifically for container-rootfs-relative path fix and open new ones for the other bug fixes. Keeps a cleaner history. |
plugin/v2/plugin.go
Outdated
There was a problem hiding this comment.
Lets fix this todo by adding to Manifest's privilege section. Something like "REQUEST_DEVICE_CREATION".
cc0760a to
3cce395
Compare
plugin/store/store.go
Outdated
There was a problem hiding this comment.
@anusha-ragunathan I could not change this in the caller function because I have only access to CompatPlugin interface values, and not *Plugin objects.
3eb7294 to
1362b42
Compare
|
|
Please let me know if I can assist. Looking forward to seeing this get merged for 1.13. |
|
Thanks, I'm planning to update this soon. |
|
ping @tiborvass what's the status here? |
1362b42 to
74bb539
Compare
|
Need a fresh pair of eyes reviewing this. @cpuguy83 ? |
plugin/v2/plugin.go
Outdated
plugin/manager.go
Outdated
plugin/manager.go
Outdated
There was a problem hiding this comment.
We are simply printing out the mounts, which doesnt test much. Can we use findmnt to see if the mount propagated?
|
Beyond the already commented items, code seems ok. |
There was a problem hiding this comment.
Shouldn't this be dockerCmd instead ? Doesn't seem right to not care about error at all 😓
There was a problem hiding this comment.
@vdemeester I kept err and asserted it non-nil. Realized that dockerCmd will assume non-nil error...
2e89b78 to
46c343f
Compare
plugin/manager.go
Outdated
There was a problem hiding this comment.
Is this still applicable? When does the mount leak?
plugin/v2/plugin.go
Outdated
There was a problem hiding this comment.
Lets not introduce Public fields in this struct. Refer to #29191 is making changes to make this all private and move necessary fields to a controller struct in the manager. Please review that PR and follow similar design on the new fields.
api/types/plugin.go
Outdated
There was a problem hiding this comment.
https://github.com/docker/docker/blob/master/docs/extend/config.md needs to be updated. Please do that alongside.
46c343f to
a0b59db
Compare
|
LGTM (if tests pass) |
plugin/manager.go
Outdated
There was a problem hiding this comment.
filepath.Base(p.PluginObj.Config.PropagatedMount)?
There was a problem hiding this comment.
Making sure I understand this... this is for mounting the propagated path to the plugin root (outside rootfs)?
Maybe even just use mnt instead of the mount path.
There was a problem hiding this comment.
@tiborvass : You should be using filepath.Join(p.LibRoot, p.PluginObj.ID, p.PluginObj.Config.PropagatedMount). Else mounts from different plugins with the same name will collide. Another option is to fix p.LibRoot to include the pluginID (It should have been this way in the first place)
We dont want to use hard coded mnt. We want plugin devs to specify the mount that needs propagation.
There was a problem hiding this comment.
@cpuguy83 : PropagatedMount is strictly for those plugins (typically volume and graph drivers) that need to setup mounts that need to propagated to the host.
We want plugin devs to specify which mounts need to be propagated, rather than hard coding it to a specific path.
There was a problem hiding this comment.
Right, but isn't this a singleton that's the "host" side of the mount?
There was a problem hiding this comment.
Yes. Having the same dir as the mount in the config could be less confusing. On the other hand, having a standard dir such as mnt is also reasonable. I'll let @tiborvass decide. Also, we dont have to do this in this PR.
There was a problem hiding this comment.
For start up reasons, this field is also set in plugin/manager.go. And I just realized it's set to something else. So I'll go with p.Rootfs for now.
Legacy plugins expect host-relative paths (such as for Volume.Mount). However, a containerized plugin cannot respond with a host-relative path. Therefore, this commit modifies new volume plugins' paths in Mount and List to prepend the container's rootfs path. This introduces a new PropagatedMount field in the Plugin Config. When it is set for volume plugins, RootfsPropagation is set to rshared and the path specified by PropagatedMount is bind-mounted with rshared prior to launching the container. This is so that the daemon code can access the paths returned by the plugin from the host mount namespace. Signed-off-by: Tibor Vass <tibor@docker.com>
a0b59db to
c54b717
Compare
Legacy plugins expect host-relative paths (such as for Volume.Mount).
However, a containerized plugin cannot respond with a host-relative
path. Therefore, this commit modifies new volume plugins' paths in Mount
and List to prepend the container's rootfs path.
Volume plugins that do mounts and want it to propagate to the host namespace, need to mount inside
/mnt.Signed-off-by: Tibor Vass tibor@docker.com