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";

• Deprecate --graph flag; Replace with --data-root #28696

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;

• Move the daemon/graphdriver package to storage #9758

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).