mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marco Massenzio" <ma...@mesosphere.io>
Subject Re: Review Request 33376: MESOS-2633 Moved struct Framework methods to their own implementation class.
Date Thu, 30 Apr 2015 01:06:22 GMT


> On April 29, 2015, 8:24 p.m., Joris Van Remoortere wrote:
> > src/master/framework.cpp, line 187
> > <https://reviews.apache.org/r/33376/diff/3/?file=939881#file939881line187>
> >
> >     1) Let's sync with BenH if we want to factor out logging like this. There are
arguments on both sides, so let's follow up with a discussion, and maybe add it to the style
guide!
> >     2) *If* we *do* decide to factor out the logging like this, let's change the
name to be more meaninful, or even move this function into `updateFrameworkInfo` as a lambda.
This message is clearly specific to that function, and is not usable by other functions in
`Framework`.
> >     3) Since we're in the implementation file, we can do `using std::string` and
remove the namespacing of `std::string` here.

I actually wasn't quite sure myself (and the more I think about this, the less I like my own
choice): this is just a helper function, to avoid violating the DRY Principle.
I would like to move it out of the Framework class, and just leave it the cpp file as a local
(static) helper method.
Again, to me, it scratches the itch of copy & pasted code, which I positively dislike.

If I change it to a local helper method, would that address your concerns?


> On April 29, 2015, 8:24 p.m., Joris Van Remoortere wrote:
> > src/master/framework.cpp, lines 185-186
> > <https://reviews.apache.org/r/33376/diff/3/?file=939881#file939881line185>
> >
> >     Can you find other places in the code where the TODOs are aligned like this?
> >     It's definitely neat, but it seems to be different from other places.

I actually did ask Nik - and he suggested this.
I'll check out other TODO's in the code base


> On April 29, 2015, 8:24 p.m., Joris Van Remoortere wrote:
> > src/master/framework.cpp, lines 101-102
> > <https://reviews.apache.org/r/33376/diff/3/?file=939881#file939881line101>
> >
> >     The style is either:
> >     Follow the alignment if you stay on the 1st line:
> >     ```
> >     bool Framework::hasExecutor(const SlaveID& slaveId,
> >                                 const ExecutorID& executorId)
> >     ```
> >     or
> >     Indent by 4 if you start the parameter list on a new line:
> >     ```
> >     bool Framework::hasExecutor(
> >         const SlaveID& slaveId,
> >         const ExecutorID& executorId)
> >     ```
> >     
> >     Here and the others below please!

ummm...
// 2: Don't use.
allocator->resourcesRecovered(frameworkId, slaveId,
                              resources, filters);

but I agree I had misread (4):

// 4: OK.
allocator->resourcesRecovered(
    frameworkId,
    slaveId,
    resources,
    filters);

will change


> On April 29, 2015, 8:24 p.m., Joris Van Remoortere wrote:
> > src/master/framework.cpp, line 60
> > <https://reviews.apache.org/r/33376/diff/3/?file=939881#file939881line60>
> >
> >     This is not your fault:
> >     there was a patch that got committed that changes `memory::shared_ptr` to `std::shared_ptr`.
Can you make sure that when this gets rebased that we get rid of any reference to `memory:shared_ptr`?
Thanks!

absolutely, will do.


> On April 29, 2015, 8:24 p.m., Joris Van Remoortere wrote:
> > src/master/framework.cpp, lines 40-43
> > <https://reviews.apache.org/r/33376/diff/3/?file=939881#file939881line40>
> >
> >     I think having this comment here (together with the implementation) is good.
Can we remove it from the header so we don't have it duplicated?

yep - sorry.
I'm usually careful about that...


- Marco


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


On April 22, 2015, 8:35 p.m., Marco Massenzio wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/33376/
> -----------------------------------------------------------
> 
> (Updated April 22, 2015, 8:35 p.m.)
> 
> 
> Review request for mesos and Joris Van Remoortere.
> 
> 
> Bugs: MESOS-2633
>     https://issues.apache.org/jira/browse/MESOS-2633
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Created new file framework.cpp containing all the methods' implementations for the `Framework`
class (declared in master/master.hpp)
> 
> Declared `operator ==` for Task in type_utils.hpp 
> (it was implemented before, but not declared in the header file);
> 
> Refactored all the LOG(WARNING) to a single utility method.
> 
> 
> Diffs
> -----
> 
>   include/mesos/type_utils.hpp cdf5864389a72002b538c263d70bcade2bdffa45 
>   src/Makefile.am 93c7c8a807a33ab639be6289535bbd32022aa85b 
>   src/master/framework.cpp PRE-CREATION 
>   src/master/master.hpp 550d2c50cd01aa5830a7e7e03ab4a0240c221b15 
> 
> Diff: https://reviews.apache.org/r/33376/diff/
> 
> 
> Testing
> -------
> 
> All tests (make check) pass.
> 
> 
> Thanks,
> 
> Marco Massenzio
> 
>


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