mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Bannier <benjamin.bann...@mesosphere.io>
Subject Re: Review Request 43881: Added allocator metric for the number of allocations to a framework.
Date Wed, 02 Mar 2016 15:46:07 GMT


> On March 1, 2016, 12:48 p.m., Alexander Rukletsov wrote:
> > src/master/allocator/mesos/hierarchical.cpp, lines 268-272
> > <https://reviews.apache.org/r/43881/diff/9/?file=1273639#file1273639line268>
> >
> >     Does it make sense to wrap framework-related metrics in a separate struct in
metrics and hide `process::metrics::add` there? You can look here for inspiration: https://github.com/apache/mesos/blob/0fd95ccc54e4d144c3eb60e98bf77d53b6bdab63/src/master/metrics.hpp#L81

That's something I also thought about. This might be something useful more generally, so I
suggest to look at this independently of this series and fix everywhere.

What I find slightly suboptimal about the wrapper you linked to is that it would `add` and
`remove` the same metric even when the wrapper is just copied (the `MetricProcess` uses just
the name of the `Metric` to check identity). The calls `add` and `remove` return `Future<Nothing>`s
to indicate success or failure but we cannot propagate that information in an RAII way in
mesos (no exceptions). I think one would either need a type w/o copy ctr and a specific move
ctr, or a more complicated infrastructure of e.g., handlers and shared metrics in the back.


> On March 1, 2016, 12:48 p.m., Alexander Rukletsov wrote:
> > src/tests/hierarchical_allocator_tests.cpp, line 2463
> > <https://reviews.apache.org/r/43881/diff/9/?file=1273640#file1273640line2463>
> >
> >     I'm an ESL as well, but "to" sounds better than "towards" to me.

I choose *towards* since I am referring the *`framework1`'s quota*, but that might be an overly
mechanic use of the language typical a German ESL user.


- Benjamin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/43881/#review121421
-----------------------------------------------------------


On March 2, 2016, 4:43 p.m., Benjamin Bannier wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/43881/
> -----------------------------------------------------------
> 
> (Updated March 2, 2016, 4:43 p.m.)
> 
> 
> Review request for mesos, Alexander Rukletsov and Ben Mahler.
> 
> 
> Bugs: MESOS-4719
>     https://issues.apache.org/jira/browse/MESOS-4719
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> See summary.
> 
> 
> Diffs
> -----
> 
>   docs/monitoring.md 827f7073204fcf8575ca980a5571c8be4f5e4110 
>   src/master/allocator/mesos/hierarchical.cpp 24fa50f62dec10ed43089297473cc386d6ba2f78

>   src/master/allocator/mesos/metrics.hpp PRE-CREATION 
>   src/master/allocator/mesos/metrics.cpp PRE-CREATION 
>   src/tests/hierarchical_allocator_tests.cpp 5f771f02db9bd098f3cd36730cd84bf2f5e87a33

> 
> Diff: https://reviews.apache.org/r/43881/diff/
> 
> 
> Testing
> -------
> 
> make check (OS X)
> 
> I confirmed that this does not lead to general performance regressions in the allocator;
this is partially expected since the added code only inserts metrics in the allocator while
the actual work is perform asynchronously. These tests where performed with `HierarchicalAllocator_BENCHMARK_Test.DeclineOffers`
on an optimized build under OS X using clang(trunk) as compiler.
> 
> 
> Thanks,
> 
> Benjamin Bannier
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message