I know this isn't complicated to set, but if a user isn't familiar with it already it's a bit esoteric to figure out exactly where to set this -- do we have a good document we could have this error point users to when their daemon won't start?

I guess the opposite argument is that we don't want to encourage these users to continue using their current storage driver (that's kind of the whole point of this error), so perhaps making them do some basic work to figure out how is appropriate?

So, erm, yes, I actually went looking for a good location (and was thinking to add an easy-to-type /go/<something> URL for that, e.g. https://docs.docker.com/go/storage-driver); the point was that when I looked at https://docs.docker.com/storage/storagedriver/select-storage-driver/, I noticed there's a wall of text about storage drivers, but that page itself doesn't show how to configure which driver to use. For that, you'd have to go to the docs for one of the individual drivers, e.g. https://docs.docker.com/storage/storagedriver/overlayfs-driver/, which outlines how to set the daemon.json etc.

Perhaps I should still consider that though. I wanted to have "something" up at least (so that it would be included in the next release), but I guess that's not there yet, so I could still tweak it (either in this PR, or as a follow-up once I have the documentation a bit improved)

There's a balancing act to be had w.r.t. actionability of the error message. The kinds of users who we most want to pay attention to the deprecation error are also the kinds of users who are most likely [citation needed] to pay no attention to what the error says and do whatever needs to be done to Just Make The Error Go Away Already. If the error message is directly actionable (i.e. "add "storage-driver": "overlay" to your daemon.json") they will act on that and forget about the important part. On the other extreme, if the user has to dig around for documentation on how to update the daemon configuration and explicitly choose a storage driver, because the error message does not contain a doc link or links to documentation which is not directly actionable, they're not going to bother to dig around and learn anything. They'll just paste the error message into Google and follow by rote whatever StackOverflow answer or Joe Blogspam's post says to do to get their daemon booting again—with the deprecated driver. Then they'll inevitably get angry when the deprecated driver is removed and they're left high and dry "because I never got any advance warning!"

IMO we need to control the messaging from the get-go: that is, link from the error message to good and actionable official documentation which details both how to migrate from overlay/aufs/devicemapper to overlay2 and how to opt into continuing to use the deprecated drivers. Make the path of least resistance lead to our messaging and we'll have a better chance at getting through to the people who most need it, and keep them away from third-party sources of information which are likely to gloss over the consequences of continuing to use the deprecated drivers.

Yes, it is more convenient to let users jump to a clear actionable document

I opened a PR in the documentation repository to add a (placeholder) https://docs.docker.com/go/storage-driver/ URL docker/docs#14435

We can update that redirect to point to a specific section once we have added more details for that; I'll update this PR to include that URL in the deprecation message(s).