Create "MAX_PER" constraint.

[EvanKrall]

For many of our applications, we'd like to limit the damage that can be caused by a single host (or AZ or whatever) going down.

For small applications, a constraint of ["hostname", "UNIQUE"] is sufficient, but when the number of instances of the application is large (similar to or larger than the number of hosts in the cluster), this is too strict. On a cluster with 30 hosts and an application with 100 instances, Marathon won't be able to deploy all the instances. If the application is asking for 30 or 25 instances, Marathon may still not be able to deploy all of them, because some of the hosts may be full with other tasks.

For applications with higher numbers of instances, it's often tolerable to put more than one instance on a box. Something like this is expressible with ["hostname", "GROUP_BY", 5], which would prevent more than 6 instances in the 30-instance example from being deployed to a single box. However, my understanding is that GROUP_BY would prevent any host from having at most 1 more instance than any other host, and so the constraints could become unsatisfiable in some cases.

If Marathon had a MAX_PER constraint, such that ["hostname", "MAX_PER", "6"] would prevent more than 6 instances from being deployed on a single host, this would satisfy my requirements of not putting too many eggs in one basket, without being as strict as GROUP_BY or UNIQUE.

([x, "MAX_PER", "1"] would be equivalent to [x, "UNIQUE"].)

[janisz]

It's related to #3220 MAX_PER could be used to spread tasks evenly on a cluster

[tmmi]

Perhaps in such a way #3885