-
Notifications
You must be signed in to change notification settings - Fork 315
Add ability to create devices in a container. #6
Conversation
We currently have one way to enter an existing container. It would be beneficial to extend that to handle different set of capabilities rather than adding a method for each specific mutation we want to apply inside a container. I would love to have a single place which handles setns logic. 'nsenter enter.json' should do all the work. The config should carry the command to run inside and any capability and permissions that the command might need. It feels like that will solve a larger set of problems. |
@rjnagal You are right but that sounds more like a refactoring job that should be done by the maintainer. Ive also learned you can try to 'future proof' things too much sometimes. IMO for now this is a reasonable way to perform a somewhat difficult problem. |
This patch add a C function to create a new device node inside the container by entering the containers mount namespace. This is used to add devices to the container at runtime. Docker-DCO-1.1-Signed-off-by: Ian Main <[email protected]> (github: imain)
* This is a C implementation to make the unlink system call in a single threaded process in the container namespace Co-Authored-By: Chris Alfonso <[email protected]> Docker-DCO-1.1-Signed-off-by: Ian Main <[email protected]> (github: imain)
@vmarmol It is pretty urgent really. I'm working on trying to get docker support back into openstack for the juno release. In order for that to happen we have to have it basically functional within the next month or so. This is a key part of that functionality. I think it would be better to merge this and then refactor afterwards. If nothing else it will give you another use case to prove your refactoring. I don't want to sound offensive at all but at some level I find the argument a bit silly.. there is maybe 15 lines of real C code here? There are hundreds of lines of golang to support device add.. this is just a small part of it and it will be just as easy to refactor with this in as without it. |
Why do you have to enter the namespaces just to do a mknod? |
My comment above was wrong. Sorry. I think we have some time to do what @rjnagal suggested. I'll close this PR for now and we can either keep discussing here or in an issue for dynamically updating a container because we will be needing this for modifying cgroups, devices, and other features. |
There is some time, yes. If that is the way you guys want to do it that's cool so long as it's done in a timely manner. I'm curious how you want to implement this? It seems to me it would be hard to get eg json into C and parse it and have a switch block of what you want to do? Also adds more complexity and is more difficult to prove it is thread safe? |
* This commit is dependent on several pull requests being merged into docker and libcontainer that expose the devadd and devrm API. moby/moby#6369 docker-archive/libcontainer#6 docker-archive/libcontainer#7 Change-Id: I6dcd7d809027bfe6ddcd9d521e519656a1ad526a
@rjnagal Do you have thoughts about the above comment? I'd like to know how we should move forward with this functionality since so many pending patches depend on this ability to mknod in a namespace. |
This patch add a C function to create a new device node inside the container
by entering the containers mount namespace. This is used to add devices
to the container at runtime.
Docker-DCO-1.1-Signed-off-by: Ian Main [email protected] (github: imain)