-
Notifications
You must be signed in to change notification settings - Fork 880
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
How do drivers decide the ethX name? #141
Comments
@shettyg Was busy integrating libnetwork with docker hence the delay in answering some of your earlier questions. Getting back to this question, the interface |
@mrjana Any update on this? This sounds like quite a significant change to the API. If you're not ready to push code for it, could you at least update the design doc (on a branch)? |
@tomdee I am getting back to working on this. Our first priority was to settle down the libnetwork northbound apis so that we can get it integrated with docker core for which we have a PR in progress. It should probably not be that much of a change in driver API other than only IP addresses required to be returned during |
@mrjana Thanks for the quick response. That all sounds good. |
Is this (or rather, the analogous problem with Join) addressed by #193, which changed the meaning of DstName to be a prefix to which libnetwork appends an index? |
@squaremo Yes, and I think we should close this issue |
Currently it is expected that driver.CreateEndpoint() returns back the sandbox.info structure that needs to include ip, gateway, veth_inside and veth_outside information. (Where veth_inside is "The name that will be assigned to the interface once moved inside a network namespace.")
As I see it, the driver cannot return back that information because it does not know how many other endpoints will be added to the container in question. What is the thought process of the designers here?
The text was updated successfully, but these errors were encountered: