store constraints and affinities as labels

[vieux]

With this PR, you still use -e to pass constraints or affinities, but swarm store those inside a labels com.docker.swarm.affinities and com.docker.swarm.constraints on the container.

The code is much simpler and we don't leak those constraints/affinities inside the container's env anymore.

[vieux]

@abronan @aluzzardi please take a look.

[thaJeztah]

I suggested the same in docker-compose; perhaps also add a label for the version of swarm that's used to set the labels; this allows for migrating existing labels/containers in case the format changes in future.

(Reading on my phone, so it's possible its in there already, but I overlooked)

[abronan]

LGTM

@thaJeztah Yes that would be a good idea, overall I like the idea of interfering with ContainerConfig creation to inject labels needed by Swarm. This way we can inject a label for the Swarm version, one for the container Virtual ID, etc..

[aluzzardi]

I think the store (RequestedState) should be using a cluster.ContainerConfig so we serialize any extra data we might have

[abronan]

I think the store (RequestedState) should be using a cluster.ContainerConfig so we serialize any extra data we might have

And

ClusterConfig is a superset of dockerclient.ContainerConfig.
It contains everything the standard docker configuration contains plus additional fields such as constraints.
ClusterConfig manages to translation to/from dockerclient.ContainerConfig and handles backward compatibility.

👍

[vieux]

I switched to 2 keys com.docker.swarm.affinities and com.docker.swarm.constraints and added a bunch of tests

[vieux]

@aluzzardi can you please take another look and comment on the PR if I forgot something ?

[aluzzardi]

LGTM

There's just a tiny golint error

[aanm]

Is there any docs on this?