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
Allow drivers to get the name along with uuid. #139
Comments
I think there is a plan to pass driver specific config/info as part of network create in form of labels #106 (comment). Because it might not just be network name that driver may need. But I am wondering if network name can just always be passed as one of the generic labels. That shall address this right? |
@mapuri Irrespective of the resolution to the driver.Join() issue, I do not see a need to supply the name twice to the command line when that information is already available with libnetwork. |
I should have been more elaborate of my thought process. I meant the uuid for the
If my understanding above is correct, once a network/endpoint has been created libnetwork can just keep passing the uuids to the driver (for instance during join) and driver will have enough info to fetch the other details from it's own data structures. And there is no need to supply the name and other labels passed at time of create again to the driver, right? As for passing names to the command-line instead of uuids, I think wherever possible it is better to allow passing either names (and internally map them to uuids in libnetwork before calling into driver) or uuids. That shall keep the cli consistent with rest of docker cli that can consume both names and uuids today. Let me know if I am missing something. |
@mapuri |
@shettyg The name that is assigned to the network and endpoint objects are not long lasting i.e they can be replaced by something else by the user for the same object. That is why we don't pass this along to keep the driver api simple. Also this way we can make sure that the objects are referred to in a consistent manner anywhere in the cluster. If you would like to do some optimization based on names you can pass some reference as a label but please keep in mind that libnetwork will not do anything to ensure consistency of these labels across different objects i.e if you assign the same label to two different objects libnetwork will happily accept that. It's up to whoever manages the labels to ensure consistency if that is what the semantics that they want for any particular label. |
The problem for us is that we associate network names with multihost definitions in some cases; this will cause libnetwork to give us a UUID for each host that might be different, if we provided our own centralized state implementation (which we wish to do). I think we should have this freedom. We're free to discard the data if it's meaningless. I'm pretty sure we could poll the client API for this data if this is omitted, which is a pretty significant hack. |
+1 for passing supplied names to the driver as part of network and endpoint creation. The usecase is the scenario where the network driver get's some of it's information from a network controller (which will mostly not be aware of libnetwork generated UUIDs), so passing the BTW once #222 is available, this can be achieved by using labels as well but then
v/s
I understand, but the driver might need to manage other relationships as well (like mapping of UUIDs to other driver-specific labels). So I am not sure if treating
From @mavenugo reply here #129 (comment) I think libnetwork shall ensure the UUID to name mapping are seen to be same on all hosts. |
@mapuri |
@mavenugo |
@mavenugo @mrjana - I understand the worry about uniqueness, regardless if the name is what If it is not too difficult to add, I'd +1 @shettyg request to allow network/endpoint names be passed to the driver. |
@shettyg @erikh @jainvipin @mapuri There have been lots of questions regarding why When we started exposing plugin interfaces to the ecosystem the thinking was to expose interfaces at every extension point with only the absolutely necessary bits exposed at that extension point. The aim was not to create a hugely all-encompassing interface through which a full fledged application can be built. The reason is very simple. We wanted to provide enough flexibility to the end-user to pick and choose different solutions for different extension points. If we had one big interface then the user can only choose one ecosystem solution for all the layers. This is exactly the same as golang's Coming back to network driver plugin the interface it represents is to provide a driver to plumb the network path based on user request. The driver can plumb the network path using various different networking technologies as it wishes but the scope should only be about plumbing the network path. To do this job the only constructs that it needs are network ids/endpoint ids etc as long as they are guaranteed to be unique across the network(which they are). If we pass down the name along with the id then we are tying in the semantics of the id and the name to be one and the same. Which is absolutely not true. The lifetime of an id and the name are very different. And if we decide to provide a flexibility to the user in the future to have a different scope to the name then it would not be possible if we couple it with the id. On top of all this the name is not required by the driver to do it's plumbing job. Our philosophy is if something is not needed for an interface to do it's job then it should not be provided because once we provide it, it is much difficult to remove it. The name is a construct that is needed only in the management layer of the solution. So if there is an extension point for the management layer in the future then the name would definitely be a candidate to be passed down in that layer. Ultimately all of this thinking is focussed on the end user and the need for providing consistent user experience. If we define an interface in a far too wide scope or if we enable plugins to assign different semantics to a particular construct then imo it ultimately leads to incoherent user experience. Hope this clarifies our position on this matter and why we are reluctant to pass down the name via the driver api. |
Closing this one for now as based on @mrjana's reasoning above |
The user passes a "name" to libnetwork apis (for e.g., a network name or an endpoint name.). The libnetwork does not pass the same name to the driver but passes a uuid instead. IMO, the "name" is an information from the user that should ideally reach the driver. But currently libnetwork blocks it.
It would be nice if libnetwork passes this information to the driver too along with the uuid. This way, the driver can keep a relationship between the uuid that libnetwork generates and the name that the user provides.
Usecases:
The usecases is for hybrid networks where a docker container and a VM and a physical machine could be reachable to each other. IMO, this provides a good transition path from current workloads to pure-docker workloads. In this case, a network would have to be pre-created outside docker. But we can make docker aware of this network with 'docker network create'.
Even assuming that the driver has to live with this restriction, a 'docker network join' would look unwieldy and confusing looking something like:
docker network join CONTAINER NETWORK --label ENDPOINT=OS-UUID --label NETWORK=OS-UUID
The text was updated successfully, but these errors were encountered: