Description
rfc: add implementation-agnostic alternative to ContainerInspect.GraphDriver
The current container inspect response is reusing the GraphDriver.Name field to present the name of the snapshotter that's used.
docker inspect naughty_mclaren | jq .
#...
"GraphDriver": {
"Data": null,
"Name": "overlayfs"
},
#...The idea here was that snapshotter or graphdriver should in most places be an implementation detail, but information such as the storage location of the snapshots are not (at least not currently) set. In this specific case, it's confusing because the field is named after the implementation, which is wrong when using snapshotters; a long time ago, work was done to make the storage driver more "agnostic";
It was discussed to also rename the GraphDriver field #28696 (comment) (and move the graphdriver package to storage), but that part of the changes never made it through;
With snapshotters becoming the default, we should probably reconsider this;
- We can leave
GraphDriver nil if snapshotters are used
- Introduce a new struct (?) that either replaces the
GraphDriver field, or add a new struct that's only set with snapshotters.
New struct could look like;
StorageDriver {
// Type of storage driver
Type string
// Name of the storage driver
Name string
// Low-level storage metadata, provided as key/value pairs.
//
// This information is driver-specific, and depends on the storage-driver
// in use, and should be used for informational purposes only.
//
// Example: {"MergedDir":"/var/lib/docker/overlay2/ef749362d13333e65fc95c572eb525abbe0052e16e086cb64bc3b98ae9aa6d74/merged","UpperDir":"/var/lib/docker/overlay2/ef749362d13333e65fc95c572eb525abbe0052e16e086cb64bc3b98ae9aa6d74/diff","WorkDir":"/var/lib/docker/overlay2/ef749362d13333e65fc95c572eb525abbe0052e16e086cb64bc3b98ae9aa6d74/work"}
// Required: true
Data map[string]string `json:"Data,omitempty"`
}
- The
Type field would have to be discussed; we can use the field if we want to share between graphdriver and snapshotters, or anticipate other types of storage to arrive (beyond just graphdrivers and snapshotters).
- The
Name and Data fields were copied from the existing GraphDriver type, but the Data field is now omitempty to discard if there's no information
- For the
Data field, we should also consider if we want to continue using a map or if a slice is more suitable (which could be a [][2]string for key/value pairs, or something more structured).
Description
rfc: add implementation-agnostic alternative to
ContainerInspect.GraphDriverThe current
container inspectresponse is reusing theGraphDriver.Namefield to present the name of the snapshotter that's used.The idea here was that snapshotter or graphdriver should in most places be an implementation detail, but information such as the storage location of the snapshots are not (at least not currently) set. In this specific case, it's confusing because the field is named after the implementation, which is wrong when using snapshotters; a long time ago, work was done to make the storage driver more "agnostic";
It was discussed to also rename the
GraphDriverfield #28696 (comment) (and move thegraphdriverpackage tostorage), but that part of the changes never made it through;With snapshotters becoming the default, we should probably reconsider this;
GraphDrivernil if snapshotters are usedGraphDriverfield, or add a new struct that's only set with snapshotters.New struct could look like;
Typefield would have to be discussed; we can use the field if we want to share between graphdriver and snapshotters, or anticipate other types of storage to arrive (beyond just graphdrivers and snapshotters).NameandDatafields were copied from the existingGraphDrivertype, but theDatafield is nowomitemptyto discard if there's no informationDatafield, we should also consider if we want to continue using amapor if a slice is more suitable (which could be a[][2]stringfor key/value pairs, or something more structured).