In response to #8348 I have created this PR.

@shykes, @crosbymichael, @timthelion, @ibuildthecloud, @calfonso, @ewindisch, see what you guys make of it.

I almost hate to bring it up but we should also decide if it's a good idea to update the hostConfig with changes to the container.

As for writing to the host config, I am personally undecided. To me "/dev/sdb" is not a thing. It is a temporary name. Almost a pronoun of sorts. There is a reason why the ubuntu folks decided to make the move to using UUIDs in /etc/fstab, even though it was a seriously breaking change. However, not all devices have UUIDs, so that fix wouldn't help us unfortunately. Similarly though, other devices like /dev/ttyACM* are strongly ephemeral.

However, I think that devices added with --device are already added to hostconfig. So my arguments, while valid, don't hold as much weight as they might otherwise.

What is the behavior with exec? Can we use exec as a role model in deciding on the hostconfig question?

needs a man page entry too :)

@SvenDowideit , yeah yeah, there is also no implementation ;).  This PR is
basically just a proposal to get the UX down.  So no man page yet, till we
decide how this thing will actually work.  No need to write the docs twice
if we're going to re-write over and over again anyways.

---------- Původní zpráva ----------
Od: Sven Dowideit [email protected]
Komu: docker/docker [email protected]
Datum: 29. 10. 2014 2:36:25
Předmět: Re: [docker] Container device add/remove CLI/API documentation RFC
(#8826)

"

needs a man page entry too :)

—
Reply to this email directly or view it on GitHub
(#8826 (comment)).

"=

From a UX perspective, also note the issue I created on consistent naming/format for the CLI (and API); #8829

ah, roger, changing the title to reflect that.

@timthelion Yeah I'm not sure on the hostConfig either. I'll be spending some time with Eric Windisch soon so maybe we can come up with some reasonable answer.

@imain please take a look at this gist - https://gist.github.com/dims/0d1ac1a5598e0b8a72e0 i've an alternative API there

Thanks for the input @dims. I modified my proposal with input from your API.

OK, good discussion on IRC @dims. I'm going to steal your idea wholesale then; I like it. :)

The new changes make a complete add/remove/list API and CLI that uses unique ID's for each device. We should be able to remove the device using only the ID as we store the information for removal in the AllowedDevices list for the container.

@imain lgtm+1

@timthelion what do you think?

Using Ids is a good idea. It is important, however, to understand that these
are not device Ids but device mapping Ids. This should be clear in the docs
as well. I would suggest that the docs(and the unit tests, when it comes
time) include the following example.

Imagine a container has the following device mappings:

[{"Id":"1", 
"PathOnHost":"/dev/sda1", 
"PathInContainer":"/dev/xvd1", 
"CgroupPermissions":"mrw" 
}, 
{"Id":"2", 
"PathOnHost":"/dev/sda1", 
"PathInContainer":"/dev/xvd2", 
"CgroupPermissions":"mr" 
} 
] 

And you do:

docker devices remove 1 <container-id>

The container still has read only permission to access /dev/sda1. And in
order to get rid of those permissions entirely, the user must remove device
mapping 2 as well.

Note 1: How are these device mapping Ids generated? If they are random, how
will Docker, and projects outside of Docker, write unit tests? Can they be
generated as a deterministic hash? Or as natural numbers counting upwards?

@timthelion - the container is 'happy_bell' in the add case. Actually in remove we should probably specify the container.

I was planning to do random IDs. We could do a deterministic hash.. we could even just use a hash of the in-container device name as that should be unique per-container.

You know I hadn't considered the example above. That could be tricky as we'll have to go through the allowed devices and make sure there's not a second use for them.

Fixed remove and ls.

When you go through the list of allowed devices looking for duplicates make
sure you match against. Major,minor number pairs and not paths as two device
nodes can actually refer to the same device on the host as well I think.

maybe it would be better to not have ids for device mappings, but to refer
to devices by their major,minor number pairs. This would mean that, in my
example, the only possibe action would be to remove both pairs at the same
time.

@crosbymichael what do you think?

+1 for this

I'm +1 for the proposal, but I don't see us merging this anytime soon until we agreed on #8829.

I'm going to close this for now, which does NOT mean we don't want this feature. We can always reopen it later.

We know we've been slow on design discussions, and we are working on improving that bottleneck. Thanks for your contribution.

+1 for this proposal

+1 for this