There are some configurations of constraints that are obviously wrong. For example:

        "constraints": [
          ["hostname", "GROUP_BY", 3],
          ["hostname", "GROUP_BY", 4]

      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.

      Acceptance Criteria

      *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"

      Alternative considerations

      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.

      Positive lookahead:

      @ "(?=a.).s".r.findFirstIn("as")
      res7: Option[String] = Some("as")
      @ "(?=a.).s".r.findFirstIn("ds")
      res8: Option[String] = None
      @ "(?=a.).s".r.findFirstIn("ad")
      res9: Option[String] = None




            • Assignee:
              tharper Tim Harper
              ( DO NOT USE ) Orchestration Team
              Chris Lambert (Inactive), Ioannis Charalampidis, Tim Harper
            • Watchers:
              3 Start watching this issue


              • Created: