@cpuguy83 Looks cool.

Woot, tests pass!

LGTM

This is very cool, but I don't know if we're going to use it more than once or twice. I don't even know if other plugins are going to follow the same code structure than volumes. I don't want to generate code either for something that's actually very static.

I'm going to leave it for others to decide, I'm okay with either decision.

/cc @tiborvass, @icecrime

@calavera Definitely understand, fair amount of complexity in the parsing... and a great learning experience none-the-less!

I do not think this is tied to how volume is setup since all systems wanting to take advantage of plugins will need this sort of thing.
This just reads the interface type and builds out the necessary bits to be able to talk to the external plugin.
I planned to use this to replace the implementation I have for external graphdrivers here: #13777 (and already tested against it).

But again, no worries!

oh #13777 looks very interesting, I hadn't seen it either! I'd still like know hear from other people, but this is totally worth considering.

This is pretty cool indeed. In building out #13924 it became pretty clear that the volume drivers section can be left in a abstract way to only include a handful of types of remote API endpoints. At a minimum, the local driver which exists now and a remote one that calls out attach/detach instead of mount.

If there were a massive amount of plugins expected to be maintained that must be updated, then it might make sense to update them in this way. But this leads towards possibly needing another level of abstraction of the proxy that can be shared.

In #13924 I did include the proxy in each driver since they do differ slightly on the calls to the remote endpoint. Other drivers may technically leverage internal go packages and not even need the proxy.

LGTM