[proposal] Service affinity constraints
Hi All, Would be extremely useful to have more flexibility with constraints. sort of:
--constraints "service.name != myservice"
What are the current limitations in achieving this? Cheers.
@pcittadini Can you tell some real life use case for this one?
Current solution looks to be on https://github.com/docker/swarmkit/blob/6553bbe191a21d4100e5d76ace27e3d5c59ef16d/manager/scheduler/filter.go#L240-L243 so this would need new code which also supports constraints with service details.
I require to run some containers on the same host (pod-like behavior). Use cases are local volume-sharing, socket sharing, or for example simply ensuring that the database sits on the same host as the application. The latter reduces chances of downtime - eg if host1 which runs the app goes down, the app is down, but if host2 goes down which runs the dB, the app also goes down/becomes unavailable. Also performance, when they would run on the same node; all traffic stays on that node rather than going over the network. Plenty of more cases I can come up with, these are the ones I run into a lot as my swarm scales further.