Is it really necessary? The plugin itself can store the network details in global KV store. The overlay driver also persists vxlan specific details itself https://github.com/docker/libnetwork/blob/master/drivers/overlay/ov_network.go#L90-L92.

Right now, if one host creates a global network and a container is spun up on that network on another host, my driver on the second host must implement a docker client and do an inspect on the network to get all the configured options before the interfaces can be properly configured. If those options were passed along with the CreateEndpoint call this wouldn't be necessary.

If I want the plugin to talk directly to the KV store then I need to implement a library for every docker supported KV store, and still ask the docker daemon for the configuration information about the store.

It's not strictly necessary, I've worked around it by calling an inspect on the network, but adding it allows the driver to get everything it needs when it is called instead of having to query the docker daemon for additional information.

If those options were passed along with the CreateEndpoint call this wouldn't be necessary.

What are the configurations you are talking about?

If I want the plugin to talk directly to the KV store then I need to implement a library for every docker supported KV store, and still ask the docker daemon for the configuration information about the store.

Libnetwork makes use of https://github.com/docker/libkv KV interface to store global/local states. If you also use libkv, then your plugin will support every KV store libnetwork does.

Thanks, I wasn't aware of libkv, that will be very useful.

For configurations, I'm talking about the options passed to the driver on docker network create via --opt.

For configurations, I'm talking about the options passed to the driver on docker network create via --opt.

Those options already passed to remote drivers on CreateNetwork, they can persist these options if they need.

But CreateNetwork is only called on one of the hosts in a cluster. Once it's created any of the other hosts may recieve a CreateEndpoint request on a network for which it has never recieved a CreateNetwork request.

@clinta as @chenchun suggested, it is really upto the plugin to use whatever mechanism it prefers to distribute the information. Infact during the early days, we were duplicating the createnetwork call on all the nodes and the plugins used to get the info. But due to popular request from various plugin developers, we let the plugins decide how it likes to distribute the info.

Yes. libnetwork uses libkv. But the plugins should not assume that always. Infact, libnetwork may move away from libkv if we have a suitable and better alternative. But, if the drivers wishes to use libkv for its operation, sure, it is a library and available for anyone to use.

@clinta It has been detected that this issue has not received any activity in over 6 months. Can you please let us know if it is still relevant:

• For a bug: do you still experience the issue with the latest version?
• For a feature request: was your request appropriately answered in a later version?

Thank you!
This issue will be automatically closed in 1 week unless it is commented on.
For more information please refer to #1926