Conversation
Signed-off-by: Brian Goff <[email protected]>
|
/cc @crosbymichael that's doing some volumes stuff these days |
|
There have been various proposals for changes in volumes (will take some time to find them all), I suggest collecting those issues / proposals to see if the discussions on them contain additional requirements / ideas that need to be considered. I don't think all features have to be implemented, just looking at them to see if the general design needs fine-tuning to allow future expansion. |
|
@thaJeztah like #6496 ? |
|
@cpuguy83 I think there are some others that are not on that list, e.g. #9250, #7249 On summarised some of them in this comment; #7249 (comment) I'm not sure how relevant those are at this point, just that it would be good to delve through them :) edit: |
|
@thaJeztah Thanks. All these are handled by adding a volume driver, and also included in potential enhancements in the PR comment. |
There was a problem hiding this comment.
Was browsing through the code; does getDriverNameFromPath() actually return an empty string? Perhaps the logic to use "vfs" should be moved to that function, i.e., make passing an empty string to getDriverNameFromPath() to return "vfs"
There was a problem hiding this comment.
Even if it doesn't return an empty string, I still prefer to check because it is technically possible as the only contract is that the function returns a string and a string can be empty.
|
yup, my quick reading of the code makes me think #9250 can be implemented with this +1 |
|
Closing this sense the #13161 was merged. |
6 participants
Stop using vfs graphrdriver for volumes.
Create new driver interface for volumes which implements what we need for vfs and binds ("vfs" and "host" drivers).
This implements just the things we need in the drivers to get current functionality with volume drivers.
Future improvements would include:
docker run -v /foo:rw,opt1=bar,opt2)Also potential new drivers that could be built in:
Some implementation details
Volume drivers are pretty dumb in general and really enforces the concept of the system (or use in the case of the host driver) requesting
a volumesome place to store data to be placed at some host path which later gets bind-mounted into the container.The volume repo object manages (as it already does today) ref counting and generating paths to be used for volumes, then just passes the generated path to the volume driver with the expectation that the volume driver just creates the volume at the given path.
Partly this is to keep the implementation of new volume drivers pretty small, but also to help ensure that the "host" driver (aka bind mounts) can itself be implemented as a volume driver.