Virtual Container IDs

[aluzzardi]

Re-scheduling containers (see #599) means they will change ID. This is unacceptable since it's the only link between the user and a container.

Swarm should create a Virtual Swarm ID for every container that maps to an actual Physical ID from the engine.

Only the Virtual ID is exposed to the user, and Swarm maintains a mapping between the two. A rescheduled container will have a different Physical ID but the same Virtual ID.

Virtual IDs could be stored as labels, see #288.

[smothiki]

@aluzzardi what is the Use case for containers getting re-scheduled other than node fail-over. Any ways Swarm is trying to enforce a unique naming scheme for containers across the cluster . May I know more about how Virtual ID is useful.

[aluzzardi]

This is work in progress, so feedback is very much welcome.

Yes, the only re-scheduling reason (for the foreseeable future) is node fail-over.

Some reasons why we would need this:

• Centralized Container IDs: Right now, each engine creates its own IDs. They might conflict with each other on different engines. Creating them in a central place guarantees uniqueness.
• Consistent IDs: When moving a container (for instance, in case of node fail-over), its ID will change. Presenting a Virtual ID to the user would prevent that.
• ID instantly available: Right now, the scheduler (through docker create) must be synchronous since we need to return an ID through the API as soon as we return the call. Having a Virtual ID would allow Swarm to generate immediately a Virtual ID, put the container into the scheduler and return immediately to the user. Whenever the container gets actually scheduled, the Virtual ID will be mapped to an Engine ID.

In order to work easily with Virtual IDs, we would use labels to tag containers with their Virtual ID.
Running docker ps directly on an engine could display Virtual IDs as a label.
Running docker ps through Swarm could display the Engine ID as a label.

[tnachen]

So does all the docker commands will try to find the ID in both docker names/ids and also the labels virtual IDs then? ie: docker stop virtualId1

[vieux]

@tnachen yes, that's the plan. I also think that docker run should return the virtual ID, so you would use virtual ID all the time, and almost never actual container ID

[tnachen]

cool, the user experience definitely becomes a bit interesting. I think we have to tell the user this is a virtual ID, since when docker ps is called users will get confused which one to look at.
And I'm curious what will we return with docker inspect (virtualID), seems like we can return all the container infos since it's an inhereit array. There is probably some things we don't want the user to do, like link volumes from a virtual ID and so forth, but ok for users to replace docker ID with virtual ID (docker run, etc). We probably will need some documentation to explain these.

[thefallentree]

Docker use a UUID for a reason, but what's the point of using a generated ID in a swarm instance? the user should just be able to use a good name to define a "job" with a good name , that has a number of "tasks" (which is actually containers ) running in the swarm cluster.

[vieux]

Merged in #745