There are some configurations of constraints that are obviously wrong. For example:
In general it seems that there is no good motivation to specify the same constraint operator and field name. As such, I move that we should reject such configuration via a validation.
*Given* an instance of Marathon
*When* I post a new app definition containing two constraints for the same field name and operator
*Then* the app definition should be refused with a validation error, saying "Specifying multiple constraints for a given field name and operator is not allowed."
*Given* an instance of Marathon with two constraints for the same field name and operator
*When* I upgrade Marathon
*Then* the migration should refuse with an error, saying "The following app/pod ids id,id,id contain a conflicting constraint. This is not allowed. Please modify your app definition remove the extra constraint"
For many of the duplicate operators, we can safely reduce without modifying behavior:
- MAX_PER: Take the minimum
- GROUP_BY: Take the minimum
- UNIQUE: pick any
- CLUSTER: if no value specified on either, pick any. If value specified on one but not other, pick the one with a value. If value specified on both, then the constraint is always invalid. Refuse?
- IS: if same, pick one. Otherwise, refuse.
- UNLIKE: merge using positive look ahead.
- LIKE: merge using positive look ahead.