> On Sept. 15, 2020, 9:25 p.m., Benjamin Mahler wrote: > > Sorry for the delay! Two things came up as I was thinking through this one: > > > > (1) I was expecting this to be an /allocator endpoint served from the > > allocator process rather than a /master endpoint served from the master > > process. The only advantage of being served by the master process is that > > it can leverage the parallel serving logic (any others?). The major > > downside is that we have to put constraint evaluation code in the master > > related logic, although since it's abstracted well it's not currently a big > > deal (much like we did with the /roles information). > > > > The main worry about it being on /master for me, is that if we need to add > > some more information in the endpoint that needs to come from the allocator > > then it will be better placed in the allocator. The obvious example coming > > to mind is: we're going to add resource quantity constraints that make the > > way agents get excluded much more dynamic than the attribute constraints > > alone. Do we want the master evaluating those? A more difficult example is > > per-constraint metrics around evaluations / pass/fail results / latency, > > etc, those might require the master to hold a shared copy of the overall > > filtering object if we were to serve it from /master? > > > > (2) One thing I realized while thinking about future constraints: we may > > want to split apart the exclusion lists as we add more types of > > constraints. E.g. "excluded", "excluded_by_attribute_constraints", > > "excluded_by_resource_constraints", etc? Otherwise, it might be pretty > > dynamic and hard to understand from the endpoint why the agent is overall > > being excluded? > > > > Thoughts?
The extendability concerns are perfectly legitimate. Especially if we will want to report some detailed statistics at some point in the future. The parallel serving logic is not that important, as we do not expect this endpoint to be called frequently. Sure, it would be nice to avoid stalling allocator while collecting the debug information, but it doesn't seem that critical. My main concerns about moving the whole implementation into the allocator are **authentication** and **authorization**. Two options here: 1) Perform initial handling of the request in the master and extend the allocator interface with a method returning the debug information (like `Future<JSON::Object> getOfferConstraintsDebugInfo(std::vector<FrameworkID>&&)` or, maybe, returning a protobuf `Future<allocator::OfferConstraintsDebugInfo> getOfferConstraintsDebugInfo(std::vector<FrameworkID>&&)`) 2) Extend allocator options with the readonly authentication domain (for which an authenticator is already set up by the master) and the authorizer; place the whole implementation into the Mesos allocator. The slight drawback is that this way users of the authorizer interface proliferate (we are adding one more); IMO, this is not a big deal and probably even quite logical. Probably we should indeed prefer the second option: - this way, we don't add ad-hoc methods that the allocator would be obliged to implement - we keeps the debug endpoint as such separate from the allocator interface - providing an authentication realm and an authorizer to an allocator facilitates adding other authenticated authorizable HTTP endpoints to the allocator, should we ever need this in the future What do you think? - Andrei ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/72851/#review221861 ----------------------------------------------------------- On Sept. 9, 2020, 9:22 p.m., Andrei Sekretenko wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/72851/ > ----------------------------------------------------------- > > (Updated Sept. 9, 2020, 9:22 p.m.) > > > Review request for mesos and Benjamin Mahler. > > > Bugs: MESOS-10177 > https://issues.apache.org/jira/browse/MESOS-10177 > > > Repository: mesos > > > Description > ------- > > Added an endpoint for debugging offer constraints. > > > Diffs > ----- > > src/master/http.cpp f34ea54ec48065f526327252aa10c6d917a96601 > src/master/master.hpp 8c2f56a0707eed8f61147715497b64a119bb02d2 > src/master/master.cpp e99cc6b8e3610c8116e9b1feedc3d7ce9f954e1e > src/master/readonly_handler.cpp b1336f9aa849e826a78c3fe4bb83e3efeb186a31 > > > Diff: https://reviews.apache.org/r/72851/diff/2/ > > > Testing > ------- > > > Thanks, > > Andrei Sekretenko > >
