> On Sept. 15, 2020, 7: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? > > Andrei Sekretenko wrote: > 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?
With 1) I think we'd probably have to go directly to string, for the same performance reasons that motivated us to move away from constructing / destructing intermediate objects with tons of subobjects. 2) sounds reasonable to me - Benjamin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/72851/#review221861 ----------------------------------------------------------- On Sept. 9, 2020, 7: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, 7: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 > >
