Skip to content
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: don't delete net devs we didn't create #1601

Merged
merged 1 commit into from May 31, 2017

Conversation

brauner
Copy link
Member

@brauner brauner commented May 30, 2017

When we didn't create a net dev we should make sure that we don't delete it. We
can simply check whether we have index for it. If not, we didn't create it.

Closes #1600.

Signed-off-by: Christian Brauner christian.brauner@ubuntu.com

When we didn't create a net dev we should make sure that we don't delete it.  We
can simply check whether we have index for it. If not, we didn't create it.

Closes lxc#1600.

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
@stgraber
Copy link
Member

Hmm, so that sounds right in general. We may need to take a look at potential implications for LXD though as I don't think that LXD deletes the devices it adds to the container after it started.

@brauner
Copy link
Member Author

brauner commented May 30, 2017

@stgraber, wait, if LXD adds devices to the container after it started, how would LXC know about them and delete them?

@brauner
Copy link
Member Author

brauner commented May 30, 2017

Unless you add them via lxc.network.veth.pair in which case what we should do is also have lxc.network.veth.ifidx with which you can tell LXC the ifidx of a net dev in a given namespace. Imho, we should actually rarely, best never, operate directly on a veth device via name. (Although ifidxs are a problem of their own...)

@stgraber stgraber merged commit bf3e9c1 into lxc:master May 31, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants