----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/72784/#review221664 -----------------------------------------------------------
include/mesos/scheduler/scheduler.proto Lines 292-293 (original), 292-318 (patched) <https://reviews.apache.org/r/72784/#comment310730> Ditto the comment on the string equality, where I think we can simplify the naming to: RegexMatch RegexNotMatch and explain that we only support TEXT attributes, with non-TEXT getting always passed through to schedulers to do their own filtering - Benjamin Mahler On Aug. 20, 2020, 3:16 p.m., Andrei Sekretenko wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/72784/ > ----------------------------------------------------------- > > (Updated Aug. 20, 2020, 3:16 p.m.) > > > Review request for mesos and Benjamin Mahler. > > > Bugs: MESOS-10173 > https://issues.apache.org/jira/browse/MESOS-10173 > > > Repository: mesos > > > Description > ------- > > This patch adds protobuf messages for setting offer constraints > that check if agent's (pseudo)attribute matches a specified RE2 regular > expression. > > Both added contsraint predicates will evaluate to `true` when the > attribute is not TEXT. This way, schedulers will have to apply on their > own whatever filtration they do for non-TEXT attributes which happen > to be selected by the constraint's `Selector`. > > Given that in the real world schedulers seem to rarely put constraints > on attributes that are normally Scalar/Ranges, this should not prevent > them from obtaining performance benefits by setting offer constraints. > > > Diffs > ----- > > include/mesos/scheduler/scheduler.proto > 6e1639a9baf017fa87b274daeedc821389216ddc > include/mesos/v1/scheduler/scheduler.proto > eb5fdeb984b28403bd8281742bd0a5f2053863e3 > > > Diff: https://reviews.apache.org/r/72784/diff/2/ > > > Testing > ------- > > > Thanks, > > Andrei Sekretenko > >
