New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Network API should provide network details for global networks #865

Closed
clinta opened this Issue Jan 11, 2016 · 8 comments

Comments

Projects
None yet
4 participants
@clinta
Contributor

clinta commented Jan 11, 2016

The libnetwork API can be used to create a global type network and all the network details are published to the cluster KV store. But there is no easy way to interface with the KV store from a driver to retrieve that data from another node.

There are two solutions I can think of. Either an interface needs to be provided which would allow a network plugin to interface with the KV store, or an easier solution I think would be to include all the network details when calling NetworkDriver.CreateEndpoint so that the driver can create the network on the fly.

@chenchun

This comment has been minimized.

Show comment
Hide comment
@chenchun

chenchun Feb 19, 2016

Contributor

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.

Contributor

chenchun commented Feb 19, 2016

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.

@clinta

This comment has been minimized.

Show comment
Hide comment
@clinta

clinta Feb 19, 2016

Contributor

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.

Contributor

clinta commented Feb 19, 2016

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.

@chenchun

This comment has been minimized.

Show comment
Hide comment
@chenchun

chenchun Feb 21, 2016

Contributor

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.

Contributor

chenchun commented Feb 21, 2016

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.

@clinta

This comment has been minimized.

Show comment
Hide comment
@clinta

clinta Feb 21, 2016

Contributor

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.

Contributor

clinta commented Feb 21, 2016

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.

@chenchun

This comment has been minimized.

Show comment
Hide comment
@chenchun

chenchun Feb 23, 2016

Contributor

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.

Contributor

chenchun commented Feb 23, 2016

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.

@clinta

This comment has been minimized.

Show comment
Hide comment
@clinta

clinta Feb 23, 2016

Contributor

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.

Contributor

clinta commented Feb 23, 2016

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.

@mavenugo

This comment has been minimized.

Show comment
Hide comment
@mavenugo

mavenugo Feb 23, 2016

Contributor

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

Contributor

mavenugo commented Feb 23, 2016

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

@GordonTheTurtle

This comment has been minimized.

Show comment
Hide comment
@GordonTheTurtle

GordonTheTurtle Aug 30, 2017

@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

GordonTheTurtle commented Aug 30, 2017

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment