Re: Review Request 30931: Added flags to logs at master and slave startup.

[Joerg Schad]

> On March 25, 2015, 3:37 p.m., Michael Park wrote:
> > Perhaps a dumb question, but I'm wondering why the enclosing braces belong 
> > here rather than in `operator << (std::ostream& stream, const FlagsBase& 
> > flags)`?

Adressed


- Joerg


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


On March 25, 2015, 11:20 p.m., Joerg Schad wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30931/
> ---
> 
> (Updated March 25, 2015, 11:20 p.m.)
> 
> 
> Review request for mesos and Till Toenshoff.
> 
> 
> Bugs: MESOS-2323
> https://issues.apache.org/jira/browse/MESOS-2323
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Added flags to logs at master and slave startup.
> 
> 
> Diffs
> -
> 
>   src/master/master.cpp dccd7c635da4b7031cd109bd84e7f17b31777ef1 
>   src/slave/slave.cpp 31ca72463abb4ef6629983391527745bbb8df2df 
> 
> Diff: https://reviews.apache.org/r/30931/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Joerg Schad
> 
>

Re: Review Request 32105: Added << operator to stout.flags.

[Michael Park]

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


Are we changing the format to be "--key0=val0 --key1=val1 --key2=val2"?


3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp


Oops, looks like you lost an indent here.


- Michael Park


On March 25, 2015, 11:20 p.m., Joerg Schad wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32105/
> ---
> 
> (Updated March 25, 2015, 11:20 p.m.)
> 
> 
> Review request for mesos.
> 
> 
> Bugs: Mesos-2323
> https://issues.apache.org/jira/browse/Mesos-2323
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> see summary
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp 
> aedb6ab30d929b81f55270612e76009bd7850daa 
> 
> Diff: https://reviews.apache.org/r/32105/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Joerg Schad
> 
>

Re: Review Request 32506: Added output stream operators for scheduler Calls and Events.

[Michael Park]

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


LGTM!

- Michael Park


On March 25, 2015, 11:13 p.m., Vinod Kone wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32506/
> ---
> 
> (Updated March 25, 2015, 11:13 p.m.)
> 
> 
> Review request for mesos and Ben Mahler.
> 
> 
> Bugs: MESOS-1127
> https://issues.apache.org/jira/browse/MESOS-1127
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> For readable output in logs.
> 
> 
> Diffs
> -
> 
>   include/mesos/type_utils.hpp cdf5864389a72002b538c263d70bcade2bdffa45 
> 
> Diff: https://reviews.apache.org/r/32506/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Vinod Kone
> 
>

Re: Review Request 32105: Added << operator to stout.flags.

[Michael Park]

> On March 25, 2015, 3:30 p.m., Michael Park wrote:
> > 3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp, lines 
> > 592-600
> > 
> >
> > How about breaking this up in order to avoid the ad-hoc `join` code?
> > 
> > ```
> > std::vector flags;
> > 
> > foreachvalue (const flags::Flags& flag, _flags) {
> >   const Option& value = flag.stringify(_flags);
> >   if (value.isSome()) {
> > flags.push_back(value.get());
> >   }
> > }
> > 
> > return stream << join(",", flags);
> > ```
> 
> Till Toenshoff wrote:
> THat is a good approach indeed. Wont look just as nice as your example as 
> we need `key + '=' + '"' + value + '"'` , not just the value.

Yeah, Joerg pinged me offline about it. I mistakenly left out the `key`, but 
the point got across :)


- Michael


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


On March 25, 2015, 11:20 p.m., Joerg Schad wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32105/
> ---
> 
> (Updated March 25, 2015, 11:20 p.m.)
> 
> 
> Review request for mesos.
> 
> 
> Bugs: Mesos-2323
> https://issues.apache.org/jira/browse/Mesos-2323
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> see summary
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp 
> aedb6ab30d929b81f55270612e76009bd7850daa 
> 
> Diff: https://reviews.apache.org/r/32105/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Joerg Schad
> 
>

Re: Review Request 32506: Added output stream operators for scheduler Calls and Events.

[Ben Mahler]

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

Ship it!


Ship It!

- Ben Mahler


On March 25, 2015, 11:13 p.m., Vinod Kone wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32506/
> ---
> 
> (Updated March 25, 2015, 11:13 p.m.)
> 
> 
> Review request for mesos and Ben Mahler.
> 
> 
> Bugs: MESOS-1127
> https://issues.apache.org/jira/browse/MESOS-1127
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> For readable output in logs.
> 
> 
> Diffs
> -
> 
>   include/mesos/type_utils.hpp cdf5864389a72002b538c263d70bcade2bdffa45 
> 
> Diff: https://reviews.apache.org/r/32506/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Vinod Kone
> 
>

Re: Review Request 32501: Removed REQUEST call from scheduler.proto.

[Ben Mahler]

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

Ship it!


Should you be adding a TODO on 'Request' to remove it when the old driver goes 
away? Or is there a reason to leave it indefinitely?

- Ben Mahler


On March 25, 2015, 11:07 p.m., Vinod Kone wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32501/
> ---
> 
> (Updated March 25, 2015, 11:07 p.m.)
> 
> 
> Review request for mesos and Ben Mahler.
> 
> 
> Bugs: MESOS-1127
> https://issues.apache.org/jira/browse/MESOS-1127
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Removed REQUEST call because it is unused.
> 
> 
> Diffs
> -
> 
>   include/mesos/scheduler/scheduler.proto 
> 783a63ad1cc0edd86605d638046fb959cb6e97e8 
>   src/master/master.cpp dccd7c635da4b7031cd109bd84e7f17b31777ef1 
>   src/scheduler/scheduler.cpp 584b042e32865fdf875bf41ebcfb7f9c327d882a 
> 
> Diff: https://reviews.apache.org/r/32501/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Vinod Kone
> 
>

Re: Open Source re: Code Licensing & Contribution Terms

[Dave Lester]

All questions are welcome here on the the mailing list! There are no
obvious or bad questions, only those that are unanswered and details
that we've poorly communicated.

As a whole, the project itself could do a better job explaining our
relationship with Apache, and how licensing and governance works --
patches are welcome if someone wants to create a documentation page to
explain this further. Fortunately, Apache already has a number of
resources related to this that we may simply want to make more-visible.

So thanks for asking, and welcome to the project. :)

To Adam's question, if there's anything you could share here about EMC's
potential interest I'm sure folks in the community would be interested
to learn more.

Cheers,
Dave

On Wed, Mar 25, 2015, at 05:48 PM, Adam Bordelon wrote:
> In payment for asking such an obvious question, could we get a
> description
> of how you are (or are considering) using Apache Mesos at EMC? If you're
> already using Mesos in production, could we get permission to add you to
> the Powered By Mesos
>  list?
> :-)
> 
> Thanks,
> -Adam-
> 
> On Wed, Mar 25, 2015 at 2:12 PM, McCullough, Theodore <
> theodore.mccullo...@emc.com> wrote:
> 
> > Thanks, and sorry we knew this.
> >
> > -T.
> >
> > From: Chris Aniszczyk [mailto:caniszc...@gmail.com]
> > Sent: Wednesday, March 25, 2015 2:11 PM
> > To: dev@mesos.apache.org
> > Cc: McCullough, Theodore
> > Subject: Re: Open Source re: Code Licensing & Contribution Terms
> > 
> >
> > Mesos is a project at the Apache Software Foundation, code/contributions
> > to the project are governed under the Apache 2.0 License:
> > https://www.apache.org/licenses/LICENSE-2.0.html
> >
> > Committers must sign a iCLA and/or a cCLA:
> > https://www.apache.org/licenses/icla.txt
> > https://www.apache.org/licenses/cla-corporate.txt
> >
> > HTH
> >
> > On Wed, Mar 25, 2015 at 3:09 PM, Wu, Jeannie  > jeannie...@emc.com>> wrote:
> > To Whom This May Concern:
> >
> > We are in the process of surveying a number of open source project
> > regarding code licensing and contribution terms.
> >
> > Can you identify for me the open source contribution agreement or policy
> > under which one contributes code to your project?
> >
> > Should you have any questions, please do not hesitate to contact me.
> >
> > Best regards,
> >
> > Jeannie M. Wu  | Intellectual Property Paralegal
> >
> > EMC Corporation  | Office of the General Counsel | 2831 Mission College
> > Blvd. |  Santa Clara, CA  |  95054
> > Phone: 408.986.4153 | Email: jeannie...@emc.com > jeannie...@emc.com>>
> >
> > This email message and any files transmitted with it are subject to the
> > attorney-client privilege and contain confidential information intended
> > only for the person(s) to whom this email is addressed. If you have
> > received this email in error, please notify the sender immediately by phone
> > or email and destroy the original message without making a copy. Thank you.
> >
> >
> >
> > --
> > Cheers,
> >
> > Chris Aniszczyk
> > http://aniszczyk.org
> > +1 512 961 6719
> >

Re: Review Request 32500: Removed LAUNCH call from scheduler.proto.

[Ben Mahler]

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

Ship it!



include/mesos/scheduler/scheduler.proto


Ditto here, the tag numbers don't matter much, but are you planning to fill 
in the holes since we're breaking this?



include/mesos/scheduler/scheduler.proto


Just curious, are you planning on updating the tag numbers at some point or 
just going to leave the holes?



src/examples/low_level_scheduler_libprocess.cpp


Ditto here, maybe some newlines to make this a bit more readable?



src/examples/low_level_scheduler_pthread.cpp


newline here?



src/examples/low_level_scheduler_pthread.cpp


newline here?



src/examples/low_level_scheduler_pthread.cpp


newline here?



src/tests/scheduler_tests.cpp


newline here?



src/tests/scheduler_tests.cpp


newline here?


- Ben Mahler


On March 25, 2015, 11:06 p.m., Vinod Kone wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32500/
> ---
> 
> (Updated March 25, 2015, 11:06 p.m.)
> 
> 
> Review request for mesos, Ben Mahler and Jie Yu.
> 
> 
> Bugs: MESOS-1127
> https://issues.apache.org/jira/browse/MESOS-1127
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Removed LAUNCH call in favor of ACCEPT.
> 
> 
> Diffs
> -
> 
>   include/mesos/scheduler/scheduler.proto 
> 783a63ad1cc0edd86605d638046fb959cb6e97e8 
>   src/examples/low_level_scheduler_libprocess.cpp 
> 63d34eefb60d13fe2b82905c1cec9b762340e997 
>   src/examples/low_level_scheduler_pthread.cpp 
> 6d1f938660c02db75bfcbf7c8de0d941cff1920d 
>   src/master/master.cpp dccd7c635da4b7031cd109bd84e7f17b31777ef1 
>   src/scheduler/scheduler.cpp 584b042e32865fdf875bf41ebcfb7f9c327d882a 
>   src/tests/scheduler_tests.cpp 4a89a7a88b50bb8c254f5076661ce07ac9fc7657 
> 
> Diff: https://reviews.apache.org/r/32500/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Vinod Kone
> 
>

Re: Open Source re: Code Licensing & Contribution Terms

[Adam Bordelon]

In payment for asking such an obvious question, could we get a description
of how you are (or are considering) using Apache Mesos at EMC? If you're
already using Mesos in production, could we get permission to add you to
the Powered By Mesos
 list? :-)

Thanks,
-Adam-

On Wed, Mar 25, 2015 at 2:12 PM, McCullough, Theodore <
theodore.mccullo...@emc.com> wrote:

> Thanks, and sorry we knew this.
>
> -T.
>
> From: Chris Aniszczyk [mailto:caniszc...@gmail.com]
> Sent: Wednesday, March 25, 2015 2:11 PM
> To: dev@mesos.apache.org
> Cc: McCullough, Theodore
> Subject: Re: Open Source re: Code Licensing & Contribution Terms
> 
>
> Mesos is a project at the Apache Software Foundation, code/contributions
> to the project are governed under the Apache 2.0 License:
> https://www.apache.org/licenses/LICENSE-2.0.html
>
> Committers must sign a iCLA and/or a cCLA:
> https://www.apache.org/licenses/icla.txt
> https://www.apache.org/licenses/cla-corporate.txt
>
> HTH
>
> On Wed, Mar 25, 2015 at 3:09 PM, Wu, Jeannie  jeannie...@emc.com>> wrote:
> To Whom This May Concern:
>
> We are in the process of surveying a number of open source project
> regarding code licensing and contribution terms.
>
> Can you identify for me the open source contribution agreement or policy
> under which one contributes code to your project?
>
> Should you have any questions, please do not hesitate to contact me.
>
> Best regards,
>
> Jeannie M. Wu  | Intellectual Property Paralegal
>
> EMC Corporation  | Office of the General Counsel | 2831 Mission College
> Blvd. |  Santa Clara, CA  |  95054
> Phone: 408.986.4153 | Email: jeannie...@emc.com jeannie...@emc.com>>
>
> This email message and any files transmitted with it are subject to the
> attorney-client privilege and contain confidential information intended
> only for the person(s) to whom this email is addressed. If you have
> received this email in error, please notify the sender immediately by phone
> or email and destroy the original message without making a copy. Thank you.
>
>
>
> --
> Cheers,
>
> Chris Aniszczyk
> http://aniszczyk.org
> +1 512 961 6719
>

Re: Review Request 32466: Cleaned up and simplified PortMappingMesosTest.

[Jie Yu]

> On March 25, 2015, 12:57 a.m., Ben Mahler wrote:
> > src/tests/port_mapping_tests.cpp, line 1810
> > 
> >
> > Might want to confirm this compiles on 4.4 if you can.

I always use 4.4.


> On March 25, 2015, 12:57 a.m., Ben Mahler wrote:
> > src/tests/port_mapping_tests.cpp, line 1753
> > 
> >
> > Why wasn't this needed before?

OK, found the issue MESOS-2554. Added a NOTE.


> On March 25, 2015, 12:57 a.m., Ben Mahler wrote:
> > src/tests/port_mapping_tests.cpp, lines 1779-1780
> > 
> >
> > Why do you need this if you're using WillRepeatedly?

Added a NOTE.


> On March 25, 2015, 12:57 a.m., Ben Mahler wrote:
> > src/tests/port_mapping_tests.cpp, lines 1927-1933
> > 
> >
> > What was this trying to test?

I don't know, thus I removed it.


> On March 25, 2015, 12:57 a.m., Ben Mahler wrote:
> > src/tests/port_mapping_tests.cpp, lines 1854-1855
> > 
> >
> > What's this for? Can you add a comment for posterity? (i.e. why is the 
> > settle needed before the advance here).

Added a comment.


> On March 25, 2015, 12:57 a.m., Ben Mahler wrote:
> > src/tests/port_mapping_tests.cpp, lines 1916-1918
> > 
> >
> > Can we keep the comment you removed above but have it down here?
> > 
> > e.g.
> > 
> > ```
> > // Ensure that both containers (with and without network isolation) 
> > were recovered.
> > ```

Done.


> On March 25, 2015, 12:57 a.m., Ben Mahler wrote:
> > src/tests/port_mapping_tests.cpp, line 1920
> > 
> >
> > Not yours, but const & ?

Done.


> On March 25, 2015, 12:57 a.m., Ben Mahler wrote:
> > src/tests/port_mapping_tests.cpp, line 1953
> > 
> >
> > Why wasn't this needed before?

Fixed.


> On March 25, 2015, 12:57 a.m., Ben Mahler wrote:
> > src/tests/port_mapping_tests.cpp, line 1993
> > 
> >
> > Might want to check that this compiles on 4.4.

I alwasy use 4.4.


> On March 25, 2015, 12:57 a.m., Ben Mahler wrote:
> > src/tests/port_mapping_tests.cpp, line 2003
> > 
> >
> > You don't need the 'true' here.

Killed.


- Jie


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


On March 25, 2015, 12:04 a.m., Jie Yu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32466/
> ---
> 
> (Updated March 25, 2015, 12:04 a.m.)
> 
> 
> Review request for mesos, Ben Mahler, Chi Zhang, and Vinod Kone.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Cleaned up and simplified PortMappingMesosTest.
> 
> 
> Diffs
> -
> 
>   src/tests/port_mapping_tests.cpp 623840e71938791a562a32989775818275e6d37e 
> 
> Diff: https://reviews.apache.org/r/32466/diff/
> 
> 
> Testing
> ---
> 
> sudo make check
> 
> 
> Thanks,
> 
> Jie Yu
> 
>

Re: Review Request 30931: Added flags to logs at master and slave startup.

[Mesos ReviewBot]

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


Patch looks great!

Reviews applied: [32105, 30931]

All tests passed.

- Mesos ReviewBot


On March 25, 2015, 11:20 p.m., Joerg Schad wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30931/
> ---
> 
> (Updated March 25, 2015, 11:20 p.m.)
> 
> 
> Review request for mesos and Till Toenshoff.
> 
> 
> Bugs: MESOS-2323
> https://issues.apache.org/jira/browse/MESOS-2323
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Added flags to logs at master and slave startup.
> 
> 
> Diffs
> -
> 
>   src/master/master.cpp dccd7c635da4b7031cd109bd84e7f17b31777ef1 
>   src/slave/slave.cpp 31ca72463abb4ef6629983391527745bbb8df2df 
> 
> Diff: https://reviews.apache.org/r/30931/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Joerg Schad
> 
>

Re: Review Request 32466: Cleaned up and simplified PortMappingMesosTest.

[Jie Yu]

> On March 25, 2015, 11:30 p.m., Chi Zhang wrote:
> > src/tests/port_mapping_tests.cpp, line 1953
> > 
> >
> > What's the need for unsetting it here?

MESOS-2554. Added a NOTE.


- Jie


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


On March 25, 2015, 12:04 a.m., Jie Yu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32466/
> ---
> 
> (Updated March 25, 2015, 12:04 a.m.)
> 
> 
> Review request for mesos, Ben Mahler, Chi Zhang, and Vinod Kone.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Cleaned up and simplified PortMappingMesosTest.
> 
> 
> Diffs
> -
> 
>   src/tests/port_mapping_tests.cpp 623840e71938791a562a32989775818275e6d37e 
> 
> Diff: https://reviews.apache.org/r/32466/diff/
> 
> 
> Testing
> ---
> 
> sudo make check
> 
> 
> Thanks,
> 
> Jie Yu
> 
>

Re: Review Request 30546: MemIsolator: expose memory pressures for containers.

[Ben Mahler]

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


Looks great Chi, can you adjust this per my comments on the depedent review 
about renaming the "Listener" to "Counter"?


include/mesos/mesos.proto


It wasn't obvious to me initially that these reset to 0 when the slave 
restarts, could we add a brief note about that?



src/slave/containerizer/isolators/cgroups/mem.cpp


Brace on the next line, also, why the trailing semi-colon?



src/slave/containerizer/isolators/cgroups/mem.cpp


Could you remove the trailing period here?

Also, any reason you're not including the listener.error() in the message? 
Seems useful.



src/slave/containerizer/isolators/cgroups/mem.cpp


It looks like the isolators have become inconsistent about what they return 
for an unknown container (e.g. network isolator is not returning a failure for 
unknown container, but the memory/cpu isolators are).

Much like in `usage`, let's just return a Failure here rather than an empty 
result. The containerizer should understand that it destroyed this container 
and doesn't need the usage() result anymore, right?



src/slave/containerizer/isolators/cgroups/mem.cpp


Can you indent the cases?

Also, there is a bug here, I'll let you find it ;)



src/slave/containerizer/isolators/cgroups/mem.cpp


Not returning a Failure in this case (like the file parsing cases in 
`usage()` above) seems to suggest that we're not sure if the pressure counters 
can fail and so we want to proceed with the partial result.

That's good, but why not keep logging the error? (rather than erasing the 
counter upon the first issue we see). Since we're not expecting this to be 
possible (but we're not confident enough about eventfds to make this a 
Failure()) let's just print an ERROR each time we are returning a partial 
result, to make this more obvious in the logs.

This also ends up cleaning up the code, as you no longer need to keep an 
iterator around for erasing.



src/slave/containerizer/isolators/cgroups/mem.cpp


Do you need to print this? Seems unnecessary?


- Ben Mahler


On March 25, 2015, 12:03 a.m., Chi Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30546/
> ---
> 
> (Updated March 25, 2015, 12:03 a.m.)
> 
> 
> Review request for mesos, Dominic Hamon, Ian Downes, and Jie Yu.
> 
> 
> Bugs: MESOS-2136
> https://issues.apache.org/jira/browse/MESOS-2136
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> MemIsolator: expose memory pressures for containers.
> 
> 
> Diffs
> -
> 
>   include/mesos/mesos.proto 3c592d5ab3092ecbeddfaff95e0c1addc3ac58f8 
>   src/slave/containerizer/isolators/cgroups/mem.hpp 
> a00f723de61b9bccd76a2948b6d14fde7a993a8d 
>   src/slave/containerizer/isolators/cgroups/mem.cpp 
> eaeb30164e8ae8c0a703683b7cc0bf1851760c95 
>   src/tests/slave_recovery_tests.cpp 87f4a6aab27d142fa8eb7a6571f684a6ce59687e 
> 
> Diff: https://reviews.apache.org/r/30546/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Chi Zhang
> 
>

Re: Review Request 27760: Revised authenticator interface to allow for two fold implementations.

[Till Toenshoff]

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

(Updated March 25, 2015, 11:35 p.m.)


Review request for mesos, Adam B, Kapil Arya, Niklas Nielsen, and Vinod Kone.


Changes
---

Fixed possible race and reference to temporal issue (the latter triggered an 
ASF builtbot make check failure on AuthenticationTest.SchedulerFailover).


Bugs: MESOS-2050
https://issues.apache.org/jira/browse/MESOS-2050


Repository: mesos


Description
---

The initial design and implementation of the authenticator module interface 
caused issues and was not optimal for heavy lifting setup of external 
dependencies. By introducing a two fold design, this has been decoupled from 
the authentication message processing. The new design also gets us back on 
track to the goal of makeing SASL a soft dependency of mesos.


Diffs (updated)
-

  include/mesos/authentication/authenticator.hpp f66217a 
  src/authentication/cram_md5/authenticator.hpp c6f465f 
  src/authentication/cram_md5/authenticator.cpp PRE-CREATION 
  src/authentication/cram_md5/auxprop.hpp b894386 
  src/master/master.hpp 3c957ab 
  src/master/master.cpp dccd7c6 
  src/tests/cram_md5_authentication_tests.cpp 92a89c5 

Diff: https://reviews.apache.org/r/27760/diff/


Testing
---

make check


Thanks,

Till Toenshoff

Re: Review Request 32466: Cleaned up and simplified PortMappingMesosTest.

[Chi Zhang]

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



src/tests/port_mapping_tests.cpp


What's the need for unsetting it here?


- Chi Zhang


On March 25, 2015, 12:04 a.m., Jie Yu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32466/
> ---
> 
> (Updated March 25, 2015, 12:04 a.m.)
> 
> 
> Review request for mesos, Ben Mahler, Chi Zhang, and Vinod Kone.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Cleaned up and simplified PortMappingMesosTest.
> 
> 
> Diffs
> -
> 
>   src/tests/port_mapping_tests.cpp 623840e71938791a562a32989775818275e6d37e 
> 
> Diff: https://reviews.apache.org/r/32466/diff/
> 
> 
> Testing
> ---
> 
> sudo make check
> 
> 
> Thanks,
> 
> Jie Yu
> 
>

Re: Review Request 30931: Added flags to logs at master and slave startup.

[Joerg Schad]

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

(Updated March 25, 2015, 11:20 p.m.)


Review request for mesos and Till Toenshoff.


Changes
---

Adressed Bens comments.


Bugs: MESOS-2323
https://issues.apache.org/jira/browse/MESOS-2323


Repository: mesos


Description
---

Added flags to logs at master and slave startup.


Diffs (updated)
-

  src/master/master.cpp dccd7c635da4b7031cd109bd84e7f17b31777ef1 
  src/slave/slave.cpp 31ca72463abb4ef6629983391527745bbb8df2df 

Diff: https://reviews.apache.org/r/30931/diff/


Testing
---

make check


Thanks,

Joerg Schad

Re: Review Request 32105: Added << operator to stout.flags.

[Joerg Schad]

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

(Updated March 25, 2015, 11:20 p.m.)


Review request for mesos.


Changes
---

Adressed Bens and Michaels comments.


Bugs: Mesos-2323
https://issues.apache.org/jira/browse/Mesos-2323


Repository: mesos


Description
---

see summary


Diffs (updated)
-

  3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp 
aedb6ab30d929b81f55270612e76009bd7850daa 

Diff: https://reviews.apache.org/r/32105/diff/


Testing
---

make check


Thanks,

Joerg Schad

Re: Review Request 32426: Symlink the namespace handle with ContainerID for the port mapping isolator.

[Jie Yu]

> On March 25, 2015, 11 p.m., Chi Zhang wrote:
> > src/slave/containerizer/isolators/network/port_mapping.cpp, line 1414
> > 
> >
> > Here in recover, the first thing we look at is the veths on the system 
> > to determine _all_ candidates for recover or orphan cleanup. This is why 
> > veth used to be cleaned up as the last step in '_cleanup'.
> > 
> > I think you need to keep that in '_cleanup'. Maybe you can re-adjust 
> > the creation order in this patch to add veth, touch pid file, mount pid 
> > file and touch symlink in isolate, and do the reverse in '_cleanup'?

See my comments above. I don't want to re-adjust the creation order because the 
veth will be gone if the child process exits early. I would rather avoid that 
bahavior. As I already pointed out, stale bind mount is inevitable. What we 
need is a more robust cleanup logic during recovery for those stale bind mounts 
(MESOS-2547). Dropping this issue.


> On March 25, 2015, 11 p.m., Chi Zhang wrote:
> > src/slave/containerizer/isolators/network/port_mapping.cpp, line 1431
> > 
> >
> > I have to agree with Vinod that the linker and linkee made it quite 
> > hard for me to understand too. 
> > 
> > Can we use more explicit names like pidToContainerIdMap (just an 
> > example)?

We use linker-->linkee concept in libprocess as well
https://github.com/apache/mesos/blob/master/3rdparty/libprocess/src/process.cpp#L303

I could add a comment.


- Jie


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


On March 25, 2015, 6:43 p.m., Jie Yu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32426/
> ---
> 
> (Updated March 25, 2015, 6:43 p.m.)
> 
> 
> Review request for mesos, Chi Zhang, Ian Downes, and Vinod Kone.
> 
> 
> Bugs: MESOS-2528
> https://issues.apache.org/jira/browse/MESOS-2528
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Symlink the namespace handle with ContainerID for the port mapping isolator.
> 
> See ticket for details. This patch will allow a smooth upgrade (i.e., rolling 
> foward and back are both safe).
> 
> 
> Diffs
> -
> 
>   src/slave/containerizer/isolators/network/port_mapping.hpp 
> 4dd066a47d43cb1d52f93294d86309151738743e 
>   src/slave/containerizer/isolators/network/port_mapping.cpp 
> 4bf0adeeac1cb6fe59f9c2ca8d5980b1500f5ddd 
>   src/tests/port_mapping_tests.cpp 623840e71938791a562a32989775818275e6d37e 
> 
> Diff: https://reviews.apache.org/r/32426/diff/
> 
> 
> Testing
> ---
> 
> sudo make check
> 
> Many existing tests should already capture the regression. For example, 
> ROOT_CleanUpOrphanTest checks if the bind mount dir is empty after the 
> container is destroyed.
> 
> Will add a compatibility test tomorrow.
> 
> 
> Thanks,
> 
> Jie Yu
> 
>

Review Request 32509: Documented the scheduler Event/Call protobufs.

[Vinod Kone]

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

Review request for mesos and Ben Mahler.


Bugs: MESOS-1127
https://issues.apache.org/jira/browse/MESOS-1127


Repository: mesos


Description
---

See summary.


Diffs
-

  include/mesos/scheduler/scheduler.proto 
783a63ad1cc0edd86605d638046fb959cb6e97e8 

Diff: https://reviews.apache.org/r/32509/diff/


Testing
---

make check


Thanks,

Vinod Kone

Review Request 32508: Added version to the scheduler protobufs.

[Vinod Kone]

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

Review request for mesos and Ben Mahler.


Bugs: MESOS-1127
https://issues.apache.org/jira/browse/MESOS-1127


Repository: mesos


Description
---

See summary.


Diffs
-

  include/mesos/scheduler/scheduler.proto 
783a63ad1cc0edd86605d638046fb959cb6e97e8 
  src/examples/low_level_scheduler_libprocess.cpp 
63d34eefb60d13fe2b82905c1cec9b762340e997 
  src/examples/low_level_scheduler_pthread.cpp 
6d1f938660c02db75bfcbf7c8de0d941cff1920d 
  src/tests/scheduler_tests.cpp 4a89a7a88b50bb8c254f5076661ce07ac9fc7657 

Diff: https://reviews.apache.org/r/32508/diff/


Testing
---

make check


Thanks,

Vinod Kone

Review Request 32507: Moved REGISTER and REREGISTER out of scheduler Calls.

[Vinod Kone]

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

Review request for mesos and Ben Mahler.


Bugs: MESOs-1127
https://issues.apache.org/jira/browse/MESOs-1127


Repository: mesos


Description
---

This is because subscription is done before schedulers can send any calls.


Diffs
-

  include/mesos/scheduler.hpp efee2cb5fc9f24e84294ed7e05a25cf8c81c2f1a 
  include/mesos/scheduler/scheduler.proto 
783a63ad1cc0edd86605d638046fb959cb6e97e8 
  src/examples/low_level_scheduler_libprocess.cpp 
63d34eefb60d13fe2b82905c1cec9b762340e997 
  src/examples/low_level_scheduler_pthread.cpp 
6d1f938660c02db75bfcbf7c8de0d941cff1920d 
  src/master/master.cpp dccd7c635da4b7031cd109bd84e7f17b31777ef1 
  src/sched/sched.cpp 66fd2b3146568900356cc48e0f17c6720665ae80 
  src/scheduler/scheduler.cpp 584b042e32865fdf875bf41ebcfb7f9c327d882a 
  src/tests/scheduler_tests.cpp 4a89a7a88b50bb8c254f5076661ce07ac9fc7657 

Diff: https://reviews.apache.org/r/32507/diff/


Testing
---

make check


Thanks,

Vinod Kone

Review Request 32506: Added output stream operators for scheduler Calls and Events.

[Vinod Kone]

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

Review request for mesos and Ben Mahler.


Bugs: MESOS-1127
https://issues.apache.org/jira/browse/MESOS-1127


Repository: mesos


Description
---

For readable output in logs.


Diffs
-

  include/mesos/type_utils.hpp cdf5864389a72002b538c263d70bcade2bdffa45 

Diff: https://reviews.apache.org/r/32506/diff/


Testing
---

make check


Thanks,

Vinod Kone

Review Request 32505: Added SHUTDOWN scheduler call.

[Vinod Kone]

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

Review request for mesos, Benjamin Hindman and Ben Mahler.


Bugs: MESOS-1127 and MESOS-330
https://issues.apache.org/jira/browse/MESOS-1127
https://issues.apache.org/jira/browse/MESOS-330


Repository: mesos


Description
---

This is a new call added to explicitly shutdown an executor.


Diffs
-

  include/mesos/scheduler/scheduler.proto 
783a63ad1cc0edd86605d638046fb959cb6e97e8 
  src/master/master.hpp 3c957abcb54a0c23b8549c1d21d2d9277791938d 
  src/master/master.cpp dccd7c635da4b7031cd109bd84e7f17b31777ef1 
  src/messages/messages.proto 97c45c01dfcea38b1ae555c036d61e10c152c2c8 
  src/scheduler/scheduler.cpp 584b042e32865fdf875bf41ebcfb7f9c327d882a 
  src/slave/slave.hpp 19e6b44bc344c0ca509674803f401cbb4e1f47ae 
  src/slave/slave.cpp c7e65a6c095963feaa9d5fdbb519c68f8f761d16 
  src/tests/scheduler_tests.cpp 4a89a7a88b50bb8c254f5076661ce07ac9fc7657 

Diff: https://reviews.apache.org/r/32505/diff/


Testing
---

make check


Thanks,

Vinod Kone

Review Request 32504: Removed MasterInfo from REGISTER and REREGISTER scheduler calls.

[Vinod Kone]

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

Review request for mesos and Ben Mahler.


Bugs: MESOS-1127
https://issues.apache.org/jira/browse/MESOS-1127


Repository: mesos


Description
---

Removed MasterInfo from REGISTER and REREGISTER scheduler calls because they 
don't provide much value in a HTTP API world because the scheduler knows 
precisely who it is connecting to.


Diffs
-

  include/mesos/scheduler/scheduler.proto 
783a63ad1cc0edd86605d638046fb959cb6e97e8 
  src/examples/low_level_scheduler_libprocess.cpp 
63d34eefb60d13fe2b82905c1cec9b762340e997 
  src/examples/low_level_scheduler_pthread.cpp 
6d1f938660c02db75bfcbf7c8de0d941cff1920d 
  src/scheduler/scheduler.cpp 584b042e32865fdf875bf41ebcfb7f9c327d882a 

Diff: https://reviews.apache.org/r/32504/diff/


Testing
---

make check


Thanks,

Vinod Kone

Review Request 32502: Updated RECONCILE call to always specifiy slave id.

[Vinod Kone]

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

Review request for mesos and Ben Mahler.


Bugs: MESOS-1127
https://issues.apache.org/jira/browse/MESOS-1127


Repository: mesos


Description
---

Having a slave id will help us do better reconciliation.


Diffs
-

  include/mesos/scheduler/scheduler.proto 
783a63ad1cc0edd86605d638046fb959cb6e97e8 
  src/master/master.hpp 3c957abcb54a0c23b8549c1d21d2d9277791938d 
  src/master/master.cpp dccd7c635da4b7031cd109bd84e7f17b31777ef1 
  src/scheduler/scheduler.cpp 584b042e32865fdf875bf41ebcfb7f9c327d882a 
  src/tests/scheduler_tests.cpp 4a89a7a88b50bb8c254f5076661ce07ac9fc7657 

Diff: https://reviews.apache.org/r/32502/diff/


Testing
---

make check


Thanks,

Vinod Kone

Review Request 32501: Removed REQUEST call from scheduler.proto.

[Vinod Kone]

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

Review request for mesos and Ben Mahler.


Bugs: MESOS-1127
https://issues.apache.org/jira/browse/MESOS-1127


Repository: mesos


Description
---

Removed REQUEST call because it is unused.


Diffs
-

  include/mesos/scheduler/scheduler.proto 
783a63ad1cc0edd86605d638046fb959cb6e97e8 
  src/master/master.cpp dccd7c635da4b7031cd109bd84e7f17b31777ef1 
  src/scheduler/scheduler.cpp 584b042e32865fdf875bf41ebcfb7f9c327d882a 

Diff: https://reviews.apache.org/r/32501/diff/


Testing
---

make check


Thanks,

Vinod Kone

Review Request 32500: Removed LAUNCH call from scheduler.proto.

[Vinod Kone]

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

Review request for mesos, Ben Mahler and Jie Yu.


Bugs: MESOS-1127
https://issues.apache.org/jira/browse/MESOS-1127


Repository: mesos


Description
---

Removed LAUNCH call in favor of ACCEPT.


Diffs
-

  include/mesos/scheduler/scheduler.proto 
783a63ad1cc0edd86605d638046fb959cb6e97e8 
  src/examples/low_level_scheduler_libprocess.cpp 
63d34eefb60d13fe2b82905c1cec9b762340e997 
  src/examples/low_level_scheduler_pthread.cpp 
6d1f938660c02db75bfcbf7c8de0d941cff1920d 
  src/master/master.cpp dccd7c635da4b7031cd109bd84e7f17b31777ef1 
  src/scheduler/scheduler.cpp 584b042e32865fdf875bf41ebcfb7f9c327d882a 
  src/tests/scheduler_tests.cpp 4a89a7a88b50bb8c254f5076661ce07ac9fc7657 

Diff: https://reviews.apache.org/r/32500/diff/


Testing
---

make check


Thanks,

Vinod Kone

Re: Review Request 32426: Symlink the namespace handle with ContainerID for the port mapping isolator.

[Chi Zhang]

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



src/slave/containerizer/isolators/network/port_mapping.cpp


Here in recover, the first thing we look at is the veths on the system to 
determine _all_ candidates for recover or orphan cleanup. This is why veth used 
to be cleaned up as the last step in '_cleanup'.

I think you need to keep that in '_cleanup'. Maybe you can re-adjust the 
creation order in this patch to add veth, touch pid file, mount pid file and 
touch symlink in isolate, and do the reverse in '_cleanup'?



src/slave/containerizer/isolators/network/port_mapping.cpp


I have to agree with Vinod that the linker and linkee made it quite hard 
for me to understand too. 

Can we use more explicit names like pidToContainerIdMap (just an example)?



src/slave/containerizer/isolators/network/port_mapping.cpp


Is this by design that you don't want to do this section in the above for 
loop (over all files from ls)?

Also I think you can achieve this without using _linkers explictly.


- Chi Zhang


On March 25, 2015, 6:43 p.m., Jie Yu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32426/
> ---
> 
> (Updated March 25, 2015, 6:43 p.m.)
> 
> 
> Review request for mesos, Chi Zhang, Ian Downes, and Vinod Kone.
> 
> 
> Bugs: MESOS-2528
> https://issues.apache.org/jira/browse/MESOS-2528
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Symlink the namespace handle with ContainerID for the port mapping isolator.
> 
> See ticket for details. This patch will allow a smooth upgrade (i.e., rolling 
> foward and back are both safe).
> 
> 
> Diffs
> -
> 
>   src/slave/containerizer/isolators/network/port_mapping.hpp 
> 4dd066a47d43cb1d52f93294d86309151738743e 
>   src/slave/containerizer/isolators/network/port_mapping.cpp 
> 4bf0adeeac1cb6fe59f9c2ca8d5980b1500f5ddd 
>   src/tests/port_mapping_tests.cpp 623840e71938791a562a32989775818275e6d37e 
> 
> Diff: https://reviews.apache.org/r/32426/diff/
> 
> 
> Testing
> ---
> 
> sudo make check
> 
> Many existing tests should already capture the regression. For example, 
> ROOT_CleanUpOrphanTest checks if the bind mount dir is empty after the 
> container is destroyed.
> 
> Will add a compatibility test tomorrow.
> 
> 
> Thanks,
> 
> Jie Yu
> 
>

Re: Review Request 30545: cgroups: added support to listen on memory pressures.

[Ben Mahler]

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


Looks good, just a minor API suggestion below.


src/linux/cgroups.hpp


One initial confusion for me was that "Listener" seemed to suggest that it 
"listens" and tells us when an event occurs. That's generally how we've used 
the word "listener".
However, this is merely keeping a count on behalf of the caller. The caller 
cannot receive events from this.

So, could we just call this a `memory::pressure::Counter`, where you can 
get the value of the counter as follows: `Future value = 
counter.value()`? So rather than having a "Listener" that provides its 
"counter", we just have a "Counter" that provides its "value".

I think that will make this a little more intuitive, thoughts?


- Ben Mahler


On March 11, 2015, 10:30 p.m., Chi Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30545/
> ---
> 
> (Updated March 11, 2015, 10:30 p.m.)
> 
> 
> Review request for mesos, Dominic Hamon, Ian Downes, and Jie Yu.
> 
> 
> Bugs: MESOS-2136
> https://issues.apache.org/jira/browse/MESOS-2136
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> cgroups: added support to listen on memory pressures.
> 
> 
> Diffs
> -
> 
>   src/linux/cgroups.hpp e07772fec11b9bb73a44c54326f24d7ee1e8a64b 
>   src/linux/cgroups.cpp a533b319fc75abb0fc45b8f5f473f257912d21ac 
> 
> Diff: https://reviews.apache.org/r/30545/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Chi Zhang
> 
>

Re: Review Request 32346: Added failure semantics for http::Pipe::Writer.

[Jie Yu]

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

Ship it!



3rdparty/libprocess/include/process/http.hpp


Indent.



3rdparty/libprocess/src/http.cpp


either end of the pipe is closed or failed!


- Jie Yu


On March 20, 2015, 11:51 p.m., Ben Mahler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32346/
> ---
> 
> (Updated March 20, 2015, 11:51 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Jie Yu, and Joris Van Remoortere.
> 
> 
> Bugs: MESOS-2438
> https://issues.apache.org/jira/browse/MESOS-2438
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> The Pipe writer needs to be able to fail the reader when it cannot complete 
> the pipe.
> 
> For example, if we are decoding a response and we cannot parse the body, we 
> must ensure the reader of the body sees a failure isntead of EOF. This was 
> used in the subsequent patches in this chain.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/include/process/http.hpp 
> 2b366986b1f617e95bda94e07f2a0e532f5626f6 
>   3rdparty/libprocess/src/http.cpp 276cecd17364989093e6eed8e97ff3a02fb0d0ef 
>   3rdparty/libprocess/src/tests/http_tests.cpp 
> 17fb092a851e128c137152fdce57e9fb10a08bf7 
> 
> Diff: https://reviews.apache.org/r/32346/diff/
> 
> 
> Testing
> ---
> 
> Added a test.
> 
> 
> Thanks,
> 
> Ben Mahler
> 
>

Jenkins build is back to normal : mesos-reviewbot #4813

[Apache Jenkins Server]

See 

Re: Review Request 32105: Added << operator to stout.flags.

[Till Toenshoff]

> On March 25, 2015, 3:30 p.m., Michael Park wrote:
> > 3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp, lines 
> > 592-600
> > 
> >
> > How about breaking this up in order to avoid the ad-hoc `join` code?
> > 
> > ```
> > std::vector flags;
> > 
> > foreachvalue (const flags::Flags& flag, _flags) {
> >   const Option& value = flag.stringify(_flags);
> >   if (value.isSome()) {
> > flags.push_back(value.get());
> >   }
> > }
> > 
> > return stream << join(",", flags);
> > ```

THat is a good approach indeed. Wont look just as nice as your example as we 
need `key + '=' + '"' + value + '"'` , not just the value.


- Till


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


On March 17, 2015, 12:25 a.m., Joerg Schad wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32105/
> ---
> 
> (Updated March 17, 2015, 12:25 a.m.)
> 
> 
> Review request for mesos.
> 
> 
> Bugs: Mesos-2323
> https://issues.apache.org/jira/browse/Mesos-2323
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> see summary
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp 
> aedb6ab30d929b81f55270612e76009bd7850daa 
> 
> Diff: https://reviews.apache.org/r/32105/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Joerg Schad
> 
>

RE: Open Source re: Code Licensing & Contribution Terms

[McCullough, Theodore]

Thanks, and sorry we knew this.

-T.

From: Chris Aniszczyk [mailto:caniszc...@gmail.com]
Sent: Wednesday, March 25, 2015 2:11 PM
To: dev@mesos.apache.org
Cc: McCullough, Theodore
Subject: Re: Open Source re: Code Licensing & Contribution Terms 

Mesos is a project at the Apache Software Foundation, code/contributions to the 
project are governed under the Apache 2.0 License: 
https://www.apache.org/licenses/LICENSE-2.0.html

Committers must sign a iCLA and/or a cCLA:
https://www.apache.org/licenses/icla.txt
https://www.apache.org/licenses/cla-corporate.txt

HTH

On Wed, Mar 25, 2015 at 3:09 PM, Wu, Jeannie 
mailto:jeannie...@emc.com>> wrote:
To Whom This May Concern:

We are in the process of surveying a number of open source project regarding 
code licensing and contribution terms.

Can you identify for me the open source contribution agreement or policy under 
which one contributes code to your project?

Should you have any questions, please do not hesitate to contact me.

Best regards,

Jeannie M. Wu  | Intellectual Property Paralegal

EMC Corporation  | Office of the General Counsel | 2831 Mission College Blvd. | 
 Santa Clara, CA  |  95054
Phone: 408.986.4153 | Email: 
jeannie...@emc.com>

This email message and any files transmitted with it are subject to the 
attorney-client privilege and contain confidential information intended only 
for the person(s) to whom this email is addressed. If you have received this 
email in error, please notify the sender immediately by phone or email and 
destroy the original message without making a copy. Thank you.



--
Cheers,

Chris Aniszczyk
http://aniszczyk.org
+1 512 961 6719

Re: Review Request 31276: Added cgroup memory pressure listening tests.

[Jie Yu]

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


Overall looks good. Let's sync on the test body.


src/tests/cgroups_tests.cpp


Can you set the limit in the test?



src/tests/cgroups_tests.cpp


Same as that in the memory isolator, put that into a hashmap? Therefore, 
you don't need to use 'Option'.



src/tests/cgroups_tests.cpp


I would rather move those fields to each tests. They are temporary 
variables.



src/tests/cgroups_tests.cpp


This is a little unreliable and non-deterministic. Any reason why you want 
to call increaseRSS multiple times?

Can you increase the RSS once to a size right below 'limit' and keep 
reading the counter until it shows non-zero (and set a time limit for that).



src/tests/cgroups_tests.cpp


I don't quite get this part :(



src/tests/memory_test_helper.hpp


Please add a comment saying that this is a blocking call.



src/tests/memory_test_helper.hpp


I won't mention the 1MB buffer in the comment. This is impl. detail. Just 
mention you'll use a buffer and doing multiple writes. Also, don't mention the 
rounding because that's impl. detail as well. You can add a TODO in the impl.



src/tests/memory_test_helper.cpp


kill this. WE typically use lambda::function directly in the code base.



src/tests/memory_test_helper.cpp


```
return Error("Expect at least one argument");
```



src/tests/memory_test_helper.cpp


```
return Error("The first argument '" + tokens[1] +
 "' is not a byte size");
```



src/tests/memory_test_helper.cpp


Since allocateRSS is only used here, please kill the helper funciton and 
move the logic into increaseRSS



src/tests/memory_test_helper.cpp


Move this down after validation is done.

Also, s/memory/buffer/



src/tests/memory_test_helper.cpp


Ditto. Please make it more informative.



src/tests/memory_test_helper.cpp


s/bytes/size/



src/tests/memory_test_helper.cpp


Ditto.



src/tests/memory_test_helper.cpp


Why this is necessary?



src/tests/memory_test_helper.cpp


NOTE: The child ...



src/tests/memory_test_helper.cpp


Can you simply use this existing interface:
```
inline Try write(int fd, const std::string& message)
```

That means, instead of using a char[] buffer, use a string as the buffer. 
You can leverage this string constructor:
```
string (size_t n, char c);
```

That means you don't need the helper function as well. Please move the 
logics down here.



src/tests/memory_test_helper.cpp


No need to create a helper funciton for that. Please just move the hashmap 
initialization to 'execute()' below.



src/tests/memory_test_helper.cpp


YOu are not checking the result of getline. This is not a good programming 
practice. Any reason not using:
```
while (getline(cin, line) >= 0) {
  
}

if (!cin.eof()) {
  cerr << "" << endl;
  return 1;
}

return 0;
```



src/tests/memory_test_helper.cpp


WHat if the token size is 0? It's good to be defensive.
```
if (tokens.empty()) {
  cerr << "" << endl;
  return 1;
}
```



src/tests/memory_test_helper.cpp


Let's add a contains check first:
```
if (!commands.contains(tokens[0])) {
  cerr << "" << endl;
  return 1;
}

Try result = commands[tokens[0]](tokens);
```



src/tests/memory_test_helper.cpp


s/sizeof(char)/sizeof(STARTED)/



src/tests/memory_test_helper.cpp


Any reason not using process::reap(

Build failed in Jenkins: mesos-reviewbot #4812

[Apache Jenkins Server]

See 

--
[URLTrigger] A change within the response URL invocation (log)
[URLTrigger] A change within the response URL invocation (log)
Building remotely on H11 (Ubuntu ubuntu) in workspace 

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/mesos.git # timeout=10
Fetching upstream changes from https://git-wip-us.apache.org/repos/asf/mesos.git
 > git --version # timeout=10
FATAL: Failed to fetch from https://git-wip-us.apache.org/repos/asf/mesos.git
hudson.plugins.git.GitException: Failed to fetch from 
https://git-wip-us.apache.org/repos/asf/mesos.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:647)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:889)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:914)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1252)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:615)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:524)
at hudson.model.Run.execute(Run.java:1706)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:232)
Caused by: hudson.plugins.git.GitException: Failed to connect to 
https://git-wip-us.apache.org/repos/asf/mesos.git (exception: 
java.net.UnknownHostException: git-wip-us.apache.org: Name or service not known)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkCredentials(CliGitAPIImpl.java:2253)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1169)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:85)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:280)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:328)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)

Re: Review Request 32495: Fixed a regression caused by multiple cgroups base hierarchy detection.

[Ben Mahler]

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

Ship it!


Thanks!

- Ben Mahler


On March 25, 2015, 9:12 p.m., Jie Yu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32495/
> ---
> 
> (Updated March 25, 2015, 9:12 p.m.)
> 
> 
> Review request for mesos, Ben Mahler and Ian Downes.
> 
> 
> Bugs: MESOS-2548
> https://issues.apache.org/jira/browse/MESOS-2548
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Fixed a regression caused by multiple cgroups base hierarchy detection.
> 
> The previous way of getting base hierarchy is not reliable in the case of 
> cgroup co-mounts and symlinks (e.g. systemd). For example, you may see the 
> following layout:
> ```
> /sys/fs/cgroup/cpu,cpuacct
> /sys/fs/cgroup/cpu -> /sys/fs/cgroup/cpu,cpuacct
> /sys/fs/cgroup/cpuacct -> /sys/fs/cgroup/cpu,cpuacct
> ```
> 
> For subsystem 'cpuacct', the current code will report the base hierarchy to 
> be '/sys/fs/cgroup/cpu,'.
> 
> 
> Diffs
> -
> 
>   src/tests/mesos.cpp dc2a906a57b9abace4713aea8b0a47fec1c1a8a4 
> 
> Diff: https://reviews.apache.org/r/32495/diff/
> 
> 
> Testing
> ---
> 
> sudo make check
> 
> 
> Thanks,
> 
> Jie Yu
> 
>

Re: Review Request 32495: Fixed a regression caused by multiple cgroups base hierarchy detection.

[Jie Yu]

> On March 25, 2015, 9:07 p.m., Ben Mahler wrote:
> > Mind adding how this fixes the issue to the description?

Done.


- Jie


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


On March 25, 2015, 9:12 p.m., Jie Yu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32495/
> ---
> 
> (Updated March 25, 2015, 9:12 p.m.)
> 
> 
> Review request for mesos, Ben Mahler and Ian Downes.
> 
> 
> Bugs: MESOS-2548
> https://issues.apache.org/jira/browse/MESOS-2548
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Fixed a regression caused by multiple cgroups base hierarchy detection.
> 
> The previous way of getting base hierarchy is not reliable in the case of 
> cgroup co-mounts and symlinks (e.g. systemd). For example, you may see the 
> following layout:
> ```
> /sys/fs/cgroup/cpu,cpuacct
> /sys/fs/cgroup/cpu -> /sys/fs/cgroup/cpu,cpuacct
> /sys/fs/cgroup/cpuacct -> /sys/fs/cgroup/cpu,cpuacct
> ```
> 
> For subsystem 'cpuacct', the current code will report the base hierarchy to 
> be '/sys/fs/cgroup/cpu,'.
> 
> 
> Diffs
> -
> 
>   src/tests/mesos.cpp dc2a906a57b9abace4713aea8b0a47fec1c1a8a4 
> 
> Diff: https://reviews.apache.org/r/32495/diff/
> 
> 
> Testing
> ---
> 
> sudo make check
> 
> 
> Thanks,
> 
> Jie Yu
> 
>

Re: Review Request 32495: Fixed a regression caused by multiple cgroups base hierarchy detection.

[Jie Yu]

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

(Updated March 25, 2015, 9:12 p.m.)


Review request for mesos, Ben Mahler and Ian Downes.


Bugs: MESOS-2548
https://issues.apache.org/jira/browse/MESOS-2548


Repository: mesos


Description (updated)
---

Fixed a regression caused by multiple cgroups base hierarchy detection.

The previous way of getting base hierarchy is not reliable in the case of 
cgroup co-mounts and symlinks (e.g. systemd). For example, you may see the 
following layout:
```
/sys/fs/cgroup/cpu,cpuacct
/sys/fs/cgroup/cpu -> /sys/fs/cgroup/cpu,cpuacct
/sys/fs/cgroup/cpuacct -> /sys/fs/cgroup/cpu,cpuacct
```

For subsystem 'cpuacct', the current code will report the base hierarchy to be 
'/sys/fs/cgroup/cpu,'.


Diffs
-

  src/tests/mesos.cpp dc2a906a57b9abace4713aea8b0a47fec1c1a8a4 

Diff: https://reviews.apache.org/r/32495/diff/


Testing
---

sudo make check


Thanks,

Jie Yu

Re: Open Source re: Code Licensing & Contribution Terms

[Chris Aniszczyk]

Mesos is a project at the Apache Software Foundation, code/contributions to
the project are governed under the Apache 2.0 License:
https://www.apache.org/licenses/LICENSE-2.0.html

Committers must sign a iCLA and/or a cCLA:
https://www.apache.org/licenses/icla.txt
https://www.apache.org/licenses/cla-corporate.txt

HTH

On Wed, Mar 25, 2015 at 3:09 PM, Wu, Jeannie  wrote:

> To Whom This May Concern:
>
> We are in the process of surveying a number of open source project
> regarding code licensing and contribution terms.
>
> Can you identify for me the open source contribution agreement or policy
> under which one contributes code to your project?
>
> Should you have any questions, please do not hesitate to contact me.
>
> Best regards,
>
> Jeannie M. Wu  | Intellectual Property Paralegal
>
> EMC Corporation  | Office of the General Counsel | 2831 Mission College
> Blvd. |  Santa Clara, CA  |  95054
> Phone: 408.986.4153 | Email: jeannie...@emc.com
>
> This email message and any files transmitted with it are subject to the
> attorney-client privilege and contain confidential information intended
> only for the person(s) to whom this email is addressed. If you have
> received this email in error, please notify the sender immediately by phone
> or email and destroy the original message without making a copy. Thank you.
>
>


-- 
Cheers,

Chris Aniszczyk
http://aniszczyk.org
+1 512 961 6719

Re: Review Request 32495: Fixed a regression caused by multiple cgroups base hierarchy detection.

[Ben Mahler]

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


Mind adding how this fixes the issue to the description?

- Ben Mahler


On March 25, 2015, 9:02 p.m., Jie Yu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32495/
> ---
> 
> (Updated March 25, 2015, 9:02 p.m.)
> 
> 
> Review request for mesos, Ben Mahler and Ian Downes.
> 
> 
> Bugs: MESOS-2548
> https://issues.apache.org/jira/browse/MESOS-2548
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Fixed a regression caused by multiple cgroups base hierarchy detection.
> 
> 
> Diffs
> -
> 
>   src/tests/mesos.cpp dc2a906a57b9abace4713aea8b0a47fec1c1a8a4 
> 
> Diff: https://reviews.apache.org/r/32495/diff/
> 
> 
> Testing
> ---
> 
> sudo make check
> 
> 
> Thanks,
> 
> Jie Yu
> 
>

Review Request 32495: Fixed a regression caused by multiple cgroups base hierarchy detection.

[Jie Yu]

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

Review request for mesos, Ben Mahler and Ian Downes.


Bugs: MESOS-2548
https://issues.apache.org/jira/browse/MESOS-2548


Repository: mesos


Description
---

Fixed a regression caused by multiple cgroups base hierarchy detection.


Diffs
-

  src/tests/mesos.cpp dc2a906a57b9abace4713aea8b0a47fec1c1a8a4 

Diff: https://reviews.apache.org/r/32495/diff/


Testing
---

sudo make check


Thanks,

Jie Yu

Open Source re: Code Licensing & Contribution Terms

[Wu, Jeannie]

To Whom This May Concern:

We are in the process of surveying a number of open source project regarding 
code licensing and contribution terms.

Can you identify for me the open source contribution agreement or policy under 
which one contributes code to your project?

Should you have any questions, please do not hesitate to contact me.

Best regards,

Jeannie M. Wu  | Intellectual Property Paralegal

EMC Corporation  | Office of the General Counsel | 2831 Mission College Blvd. | 
 Santa Clara, CA  |  95054
Phone: 408.986.4153 | Email: jeannie...@emc.com

This email message and any files transmitted with it are subject to the 
attorney-client privilege and contain confidential information intended only 
for the person(s) to whom this email is addressed. If you have received this 
email in error, please notify the sender immediately by phone or email and 
destroy the original message without making a copy. Thank you.

Re: Review Request 29748: Added tests for Phase 1 of Dynamic Reservation.

[Alexander Rukletsov]

> On March 18, 2015, 12:29 a.m., Alexander Rukletsov wrote:
> > src/Makefile.am, line 1366
> > 
> >
> > Is one tab missing?
> 
> Michael Park wrote:
> Haha I have no idea. I see examples of lines with 1, 2 or 3 tabs, spaces, 
> etc. The example I took this line from, `tests/resource_offers_tests.cpp` has 
> one tab.

I think we insert tabs (8 chars length) so that \ align vertically.


> On March 18, 2015, 12:29 a.m., Alexander Rukletsov wrote:
> > src/tests/reservation_tests.cpp, lines 80-85
> > 
> >
> > Do we really want to do these tests for all allocator types?
> 
> Michael Park wrote:
> I don't have an argument for why we should but I don't see an argument 
> for why we shouldn't either. Would you prefer that we don't test for all 
> allocators?

I think that a custom allocator doesn't need to reserve and unreserve 
resources. We introduce this feature into our allocator, but I'm not sure we 
enforce any allocator to account for reservations.


> On March 18, 2015, 12:29 a.m., Alexander Rukletsov wrote:
> > src/tests/reservation_tests.cpp, lines 218-222
> > 
> >
> > Shouldn't we `driver.start();` here between setting an expectation and 
> > awaiting offers? Ditto above and below.
> 
> Michael Park wrote:
> I think you're right. Am I getting lucky in race conditions here? or is 
> this a valid way to write tests, just not preferred?

I guess you're lucky. You can insert `sleep(20)` and check it out : ).


> On March 18, 2015, 12:29 a.m., Alexander Rukletsov wrote:
> > src/tests/reservation_tests.cpp, lines 253-255
> > 
> >
> > What do you check with this expectation?
> 
> Michael Park wrote:
> This was taken from other tests that do this. I thought it was there to 
> suppress the `Uninteresting mock function call` warning, but I removed it and 
> I don't see any warnings. Do you know what conditions trigger the warning?

We suppress warnings in a different way, see e.g. `TestAllocator`.


> On March 18, 2015, 12:29 a.m., Alexander Rukletsov wrote:
> > src/tests/reservation_tests.cpp, line 271
> > 
> >
> > Can we merge this test with the previous one?
> 
> Michael Park wrote:
> By "merge" do you mean I can remove the previous since this is a superset 
> of it?
> 
> Michael Park wrote:
> If yes, I did that. Otherwise, please let me know what you would like 
> done here :)

Yes, you're reading my thougts well! : )


> On March 18, 2015, 12:29 a.m., Alexander Rukletsov wrote:
> > src/tests/reservation_tests.cpp, lines 311-312
> > 
> >
> > Ensure `frameworkId` is set by awaiting. Ditto above and below.
> 
> Michael Park wrote:
> I've added the `AWAIT_READY`s since we use that pattern for `offer`s 
> everywhere. But a `Future`'s `get` function waits if it's not ready yet. I 
> suppose we prefer to be explicit in our tests?

I personally find it much easier to read and understand your intention: when do 
you expect a certain action to be completed.


> On March 18, 2015, 12:29 a.m., Alexander Rukletsov wrote:
> > src/tests/reservation_tests.cpp, lines 337-338
> > 
> >
> > Again, do we need to set this explicitly?
> 
> Michael Park wrote:
> Removing this results in `Uninteresting mock function call` warnings from 
> `gmock`.

Makes sense.


- Alexander


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


On March 23, 2015, 5:21 p.m., Michael Park wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/29748/
> ---
> 
> (Updated March 23, 2015, 5:21 p.m.)
> 
> 
> Review request for mesos, Alexander Rukletsov, Ben Mahler, and Jie Yu.
> 
> 
> Bugs: MESOS-2489
> https://issues.apache.org/jira/browse/MESOS-2489
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> See summary.
> 
> 
> Diffs
> -
> 
>   src/Makefile.am 7a06c7028eca8164b1f5fdea6a7ecd37ee6826bb 
>   src/tests/reservation_tests.cpp PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/29748/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Michael Park
> 
>

Re: Review Request 26147: Remove non-variadic strings::format() implementation

[Cody Maloney]

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

(Updated March 25, 2015, 8:02 p.m.)


Review request for mesos, Benjamin Hindman, Dominic Hamon, and Niklas Nielsen.


Changes
---

Add JIRA


Bugs: MESOS-2549
https://issues.apache.org/jira/browse/MESOS-2549


Repository: mesos


Description
---

Variadic templates are supported by all our compilers and are already
relied on by stout (, ).


Diffs
-

  3rdparty/libprocess/3rdparty/stout/include/stout/format.hpp 
58ab7424c9645fd04d6aea2e4ff56c1ff9815953 

Diff: https://reviews.apache.org/r/26147/diff/


Testing
---

Make distcheck ubuntu 14.04

Compiled with gcc 4.4


Thanks,

Cody Maloney

Re: Review Request 32150: Enable the master to handle reservation operations.

[Alexander Rukletsov]

> On March 18, 2015, 12:29 a.m., Alexander Rukletsov wrote:
> > src/master/master.cpp, line 2412
> > 
> >
> > Should we log here?
> 
> Michael Park wrote:
> We log inside the `drop` function already. Do you mean we should log 
> around this particular call-site?

No, I missed the comment, sorry for the noise.


- Alexander


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


On March 19, 2015, 7:06 p.m., Michael Park wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32150/
> ---
> 
> (Updated March 19, 2015, 7:06 p.m.)
> 
> 
> Review request for mesos, Alexander Rukletsov, Ben Mahler, and Jie Yu.
> 
> 
> Bugs: MESOS-2139
> https://issues.apache.org/jira/browse/MESOS-2139
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Handled reservation operations in `Master::_accept`.
> 
> Added `validate` functions in `src/master/validation.{hpp,cpp}`.
> 
> 
> Diffs
> -
> 
>   src/master/master.cpp dccd7c635da4b7031cd109bd84e7f17b31777ef1 
>   src/master/validation.hpp 2d7416c053f82d6316542fa9c35b0e7bc605abec 
>   src/master/validation.cpp 2f2e4ea8ea123c5a0d01446cdec8b308ea60932e 
>   src/tests/master_validation_tests.cpp 
> c8742928a4e93e86ccd0f5a39856a65cfe8eb74f 
> 
> Diff: https://reviews.apache.org/r/32150/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Michael Park
> 
>

Re: Review Request 32140: Enable 'Resources' to handle 'Resource::ReservationInfo'.

[Alexander Rukletsov]

> On March 18, 2015, 12:27 a.m., Alexander Rukletsov wrote:
> > src/common/resources.cpp, lines 44-49
> > 
> >
> > Why these operatos (also those that were here before) are defined here 
> > and not in `include/mesos/type_utils.{hpp|cpp}`?
> 
> Michael Park wrote:
> I defined them here to keep consistency with the operators for 
> `DiskInfo`. I think it's because we don't really need these comparators 
> outside of this file. @jieyu: What do you think?
> 
> Jie Yu wrote:
> Mpark, you are right. The DiskInfo == operator is only used in 
> resources.cpp currently. Also, we usually keep the operator close to the 
> corresponding class. For example, we put operator == of Value::Scalar in 
> src/common/values.cpp rather than type_utils.hpp.

I prefer to keep similar stuff in similar places for the principal of least 
surprise, but I let you guys decide. I don't think we can appeal to consistency 
here, since one case (`DiskInfo` operators) is not a statistic. Feel free to 
drop.


> On March 18, 2015, 12:27 a.m., Alexander Rukletsov wrote:
> > src/common/resources.cpp, lines 69-74
> > 
> >
> > Not yours, but resently, Vinod did a cleanup in equivalence operators 
> > for our proto messages in `type_utils.{hpp|cpp}`: 
> > https://reviews.apache.org/r/31904/. I think we should do the same here for 
> > consistency (most probably in a separate RR). Also, one more point to 
> > extract these out to `type_utils`.
> 
> Michael Park wrote:
> Hm, I actually missed that review request. That pattern of comparisons 
> don't always work... doesn't seem like good practice to me.
> 
> In particular, it doesn't work when "unset" and the "default" message 
> mean different things. Consider our `ReservationInfo` example:
> 
> The (role, reservation) pairs:
>   - ("role", None) means statically reserved for "role"
>   - ("role", { framework_id: None }) means dynamically reserved for "role"
> 
> If we compare by `left.reservation() == right.reservation()`, the 2 
> states above are considered equal because `left.reservation()` returns `{ 
> framework_id: None }`, according to [protobuf 
> documentation](https://developers.google.com/protocol-buffers/docs/cpptutorial):
> > optional: the field may or may not be set. If an optional field value 
> isn't set, a default value is used. For simple types, you can specify your 
> own default value, as we've done for the phone number type in the example. 
> Otherwise, a system default is used: zero for numeric types, the empty string 
> for strings, false for bools. **For embedded messages, the default value is 
> always the "default instance" or "prototype" of the message, which has none 
> of its fields set. Calling the accessor to get the value of an optional (or 
> required) field which has not been explicitly set always returns that field's 
> default value.**
> 
> We actually do need to check for `has_` conditions to get it right.
> ```
> left.has_reservation() == right.has_reservation() && 
> (!left.has_reservation() || left.reservation() == right.reservation());
> ```
> `DiskInfo` is another embdedded message that has all optional fields 
> similar to `ReservationInfo`, except its "unset" is equivalent to "default" 
> message. So doing `left.disk() == right.disk()` works.

The problem with `has_*()` checks is that if you specify the value which is 
equal to the default, you check will fail and messages will be considered 
different.


- Alexander


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


On March 20, 2015, 10:36 p.m., Michael Park wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32140/
> ---
> 
> (Updated March 20, 2015, 10:36 p.m.)
> 
> 
> Review request for mesos, Alexander Rukletsov, Ben Mahler, and Jie Yu.
> 
> 
> Bugs: MESOS-2476
> https://issues.apache.org/jira/browse/MESOS-2476
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> `Resource::ReservationInfo` was introduced in 
> [r32139](https://reviews.apache.org/r/32139). We need to consider it in our 
> `Resources` class implementation.
> 
> ### `Resources::flatten`
> 
> `flatten` is used as the utility function to cross reservation boundaries 
> without affecting the given resources. Since the reservation is now specified 
> by the (`role`, `reservation`) pair, `flatten` needs to consider 
> `ReservationInfo` as well.
> 
> ### `Resources::validate`
> 
> If `role == "*"`, then `reservation` field must not be set.
> 
> ### `Resources`

Re: Review Request 32426: Symlink the namespace handle with ContainerID for the port mapping isolator.

[Mesos ReviewBot]

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


Patch looks great!

Reviews applied: [32426]

All tests passed.

- Mesos ReviewBot


On March 25, 2015, 6:43 p.m., Jie Yu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32426/
> ---
> 
> (Updated March 25, 2015, 6:43 p.m.)
> 
> 
> Review request for mesos, Chi Zhang, Ian Downes, and Vinod Kone.
> 
> 
> Bugs: MESOS-2528
> https://issues.apache.org/jira/browse/MESOS-2528
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Symlink the namespace handle with ContainerID for the port mapping isolator.
> 
> See ticket for details. This patch will allow a smooth upgrade (i.e., rolling 
> foward and back are both safe).
> 
> 
> Diffs
> -
> 
>   src/slave/containerizer/isolators/network/port_mapping.hpp 
> 4dd066a47d43cb1d52f93294d86309151738743e 
>   src/slave/containerizer/isolators/network/port_mapping.cpp 
> 4bf0adeeac1cb6fe59f9c2ca8d5980b1500f5ddd 
>   src/tests/port_mapping_tests.cpp 623840e71938791a562a32989775818275e6d37e 
> 
> Diff: https://reviews.apache.org/r/32426/diff/
> 
> 
> Testing
> ---
> 
> sudo make check
> 
> Many existing tests should already capture the regression. For example, 
> ROOT_CleanUpOrphanTest checks if the bind mount dir is empty after the 
> container is destroyed.
> 
> Will add a compatibility test tomorrow.
> 
> 
> Thanks,
> 
> Jie Yu
> 
>

Re: Review Request 32139: Add 'Resource::ReservationInfo' protobuf message.

[Alexander Rukletsov]

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



include/mesos/mesos.proto


MPark, sorry if I leave the comment in a wrong place, I don't know where we 
discuss the design now. I'm sure you'll point me to the right doc : ).

Q1: Do we allow frameworks to reserve dynamically for role, or just 
operators?

Q2: If the answer to Q1 is "no", does it make sense to distinguish between 
static reservations and dynamic reservations since both of them are done by an 
operator?

Q3: If the answer to Q2 is "yes", how are we going to distinguish between 
framework and operator dynamic *role* reservations if we introduce framework 
role reservations one day?



include/mesos/mesos.proto


Let's insert a whitespace `"*" | R` if you are going to edit this.


- Alexander Rukletsov


On March 25, 2015, 6:47 p.m., Michael Park wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32139/
> ---
> 
> (Updated March 25, 2015, 6:47 p.m.)
> 
> 
> Review request for mesos, Alexander Rukletsov, Ben Mahler, and Jie Yu.
> 
> 
> Bugs: MESOS-2475
> https://issues.apache.org/jira/browse/MESOS-2475
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> The beginning of `Resource::ReservationInfo`. This patch only introduces the 
> `framework_id` field. We don't need the required `principal` field yet and 
> will be introduced together with the "unreserve" ACLs. An optional `id` may 
> be introduced in the future as well.
> 
> 
> Diffs
> -
> 
>   include/mesos/mesos.proto 3c592d5ab3092ecbeddfaff95e0c1addc3ac58f8 
> 
> Diff: https://reviews.apache.org/r/32139/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Michael Park
> 
>

Re: Review Request 32139: Add 'Resource::ReservationInfo' protobuf message.

[Michael Park]

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

(Updated March 25, 2015, 6:47 p.m.)


Review request for mesos, Alexander Rukletsov, Ben Mahler, and Jie Yu.


Changes
---

Updated the comment for the `reservation` field, Removed the list of valid 
states/transitions for (role, reservation) pair. I'll update this with a link 
to the user guide when the user guide is ready to be added to the repo.


Bugs: MESOS-2475
https://issues.apache.org/jira/browse/MESOS-2475


Repository: mesos


Description
---

The beginning of `Resource::ReservationInfo`. This patch only introduces the 
`framework_id` field. We don't need the required `principal` field yet and will 
be introduced together with the "unreserve" ACLs. An optional `id` may be 
introduced in the future as well.


Diffs (updated)
-

  include/mesos/mesos.proto 3c592d5ab3092ecbeddfaff95e0c1addc3ac58f8 

Diff: https://reviews.apache.org/r/32139/diff/


Testing
---

make check


Thanks,

Michael Park

Re: Review Request 32139: Add 'Resource::ReservationInfo' protobuf message.

[Michael Park]

> On March 24, 2015, 7:25 a.m., Timothy Chen wrote:
> > include/mesos/mesos.proto, line 397
> > 
> >
> > Not sure this is the right place to comment on the valid specifications 
> > of both role and reservation. There is a user guide added right? We should 
> > refer to that instead.
> 
> Michael Park wrote:
> Hm, the user guide doesn't exist in the repo. Maybe we just say something 
> like: "Refer to the reservations user guide for the valid states and 
> transitions of (role, reservation) pair." and add in the links together with 
> the user guide later?

It seems weird to refer to a user guide that doesn't exist yet. I'll add the 
comment here with the link to the user guide when the user guide is ready to be 
added to the repo.


- Michael


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


On March 25, 2015, 6:47 p.m., Michael Park wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32139/
> ---
> 
> (Updated March 25, 2015, 6:47 p.m.)
> 
> 
> Review request for mesos, Alexander Rukletsov, Ben Mahler, and Jie Yu.
> 
> 
> Bugs: MESOS-2475
> https://issues.apache.org/jira/browse/MESOS-2475
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> The beginning of `Resource::ReservationInfo`. This patch only introduces the 
> `framework_id` field. We don't need the required `principal` field yet and 
> will be introduced together with the "unreserve" ACLs. An optional `id` may 
> be introduced in the future as well.
> 
> 
> Diffs
> -
> 
>   include/mesos/mesos.proto 3c592d5ab3092ecbeddfaff95e0c1addc3ac58f8 
> 
> Diff: https://reviews.apache.org/r/32139/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Michael Park
> 
>

Re: Updating Mesos website + blog post for 0.22.0 release

[Dave Lester]

Thanks for sharing -- looks good! I just added a few minor suggestions.

Dave

On Wed, Mar 25, 2015, at 11:33 AM, Niklas Nielsen wrote:
> Hey Dave,
>
> Thanks for reaching out! I wrote a draft post immediately after
> releasing and getting some proof reading done:
> https://docs.google.com/a/mesosphere.io/document/d/1GHbdu9A22UuN2UHIjQXheJ7oNaO84W-p2lbriAHo8FI/edit
>
> Think I have things setup correctly, but I'd be happy to share a patch
> first before committing :)
>
> Thanks! Niklas
>
> On 25 March 2015 at 11:30, Dave Lester  wrote:
>> Hey Niklas,
>>
>>
Now that 0.22.0 has passed, are you planning to update the Mesos website
>>
and draft a blog post announcement? Any ETA?
>>
>>
I'm happy to help review this or answer any questions if you have any
>>
re: the site or blog -- I think Tim Chen ran into a few issues to update
>>
for the last release (due to a lack of documentation), and I'd like to
>>
make sure this is fairly straight-forward for committers moving forward.
>>
>>
Best,
>>
Dave
>

Re: Review Request 32426: Symlink the namespace handle with ContainerID for the port mapping isolator.

[Jie Yu]

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

(Updated March 25, 2015, 6:43 p.m.)


Review request for mesos, Chi Zhang, Ian Downes, and Vinod Kone.


Changes
---

Review comments.


Bugs: MESOS-2528
https://issues.apache.org/jira/browse/MESOS-2528


Repository: mesos


Description
---

Symlink the namespace handle with ContainerID for the port mapping isolator.

See ticket for details. This patch will allow a smooth upgrade (i.e., rolling 
foward and back are both safe).


Diffs (updated)
-

  src/slave/containerizer/isolators/network/port_mapping.hpp 
4dd066a47d43cb1d52f93294d86309151738743e 
  src/slave/containerizer/isolators/network/port_mapping.cpp 
4bf0adeeac1cb6fe59f9c2ca8d5980b1500f5ddd 
  src/tests/port_mapping_tests.cpp 623840e71938791a562a32989775818275e6d37e 

Diff: https://reviews.apache.org/r/32426/diff/


Testing
---

sudo make check

Many existing tests should already capture the regression. For example, 
ROOT_CleanUpOrphanTest checks if the bind mount dir is empty after the 
container is destroyed.

Will add a compatibility test tomorrow.


Thanks,

Jie Yu

Re: Review Request 32426: Symlink the namespace handle with ContainerID for the port mapping isolator.

[Jie Yu]

> On March 24, 2015, 2:15 p.m., Alexander Rojas wrote:
> > src/slave/containerizer/isolators/network/port_mapping.cpp, line 1449
> > 
> >
> > I don't have any solution for this, but I feel that if any other 
> > application creates a symlink in the `PORT_MAPPING_BIND_MOUNT_ROOT()`, then 
> > it will be parsed as a `ContainerID`, since its value is nothing but a 
> > string.
> > 
> > Perhaps we should discuss ideas on how to validate that an ID is 
> > actually an ID.

I added a TODO in the code.


- Jie


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


On March 25, 2015, 6:43 p.m., Jie Yu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32426/
> ---
> 
> (Updated March 25, 2015, 6:43 p.m.)
> 
> 
> Review request for mesos, Chi Zhang, Ian Downes, and Vinod Kone.
> 
> 
> Bugs: MESOS-2528
> https://issues.apache.org/jira/browse/MESOS-2528
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Symlink the namespace handle with ContainerID for the port mapping isolator.
> 
> See ticket for details. This patch will allow a smooth upgrade (i.e., rolling 
> foward and back are both safe).
> 
> 
> Diffs
> -
> 
>   src/slave/containerizer/isolators/network/port_mapping.hpp 
> 4dd066a47d43cb1d52f93294d86309151738743e 
>   src/slave/containerizer/isolators/network/port_mapping.cpp 
> 4bf0adeeac1cb6fe59f9c2ca8d5980b1500f5ddd 
>   src/tests/port_mapping_tests.cpp 623840e71938791a562a32989775818275e6d37e 
> 
> Diff: https://reviews.apache.org/r/32426/diff/
> 
> 
> Testing
> ---
> 
> sudo make check
> 
> Many existing tests should already capture the regression. For example, 
> ROOT_CleanUpOrphanTest checks if the bind mount dir is empty after the 
> container is destroyed.
> 
> Will add a compatibility test tomorrow.
> 
> 
> Thanks,
> 
> Jie Yu
> 
>

Re: Review Request 32139: Add 'Resource::ReservationInfo' protobuf message.

[Michael Park]

> On March 24, 2015, 7:25 a.m., Timothy Chen wrote:
> > include/mesos/mesos.proto, line 397
> > 
> >
> > Not sure this is the right place to comment on the valid specifications 
> > of both role and reservation. There is a user guide added right? We should 
> > refer to that instead.

Hm, the user guide doesn't exist in the repo. Maybe we just say something like: 
"Refer to the reservations user guide for the valid states and transitions of 
(role, reservation) pair." and add in the links together with the user guide 
later?


> On March 24, 2015, 7:25 a.m., Timothy Chen wrote:
> > include/mesos/mesos.proto, line 428
> > 
> >
> > It also can be unreserved as well?

If the `reservation` is not set, it's either "statically reserved" or 
"unreserved". I cheated here by saying "statically configured", perhaps that's 
confusing. I'll explicitly mention "statically reserved" and "unreserved".


- Michael


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


On March 18, 2015, 7:43 p.m., Michael Park wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32139/
> ---
> 
> (Updated March 18, 2015, 7:43 p.m.)
> 
> 
> Review request for mesos, Alexander Rukletsov, Ben Mahler, and Jie Yu.
> 
> 
> Bugs: MESOS-2475
> https://issues.apache.org/jira/browse/MESOS-2475
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> The beginning of `Resource::ReservationInfo`. This patch only introduces the 
> `framework_id` field. We don't need the required `principal` field yet and 
> will be introduced together with the "unreserve" ACLs. An optional `id` may 
> be introduced in the future as well.
> 
> 
> Diffs
> -
> 
>   include/mesos/mesos.proto ec8efaec13f54a56d82411f6cdbdb8ad8b103748 
> 
> Diff: https://reviews.apache.org/r/32139/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Michael Park
> 
>

Re: Updating Mesos website + blog post for 0.22.0 release

[Niklas Nielsen]

Hey Dave,

Thanks for reaching out! I wrote a draft post immediately after releasing
and getting some proof reading done:
https://docs.google.com/a/mesosphere.io/document/d/1GHbdu9A22UuN2UHIjQXheJ7oNaO84W-p2lbriAHo8FI/edit

Think I have things setup correctly, but I'd be happy to share a patch
first before committing :)

Thanks!
Niklas

On 25 March 2015 at 11:30, Dave Lester  wrote:

> Hey Niklas,
>
> Now that 0.22.0 has passed, are you planning to update the Mesos website
> and draft a blog post announcement? Any ETA?
>
> I'm happy to help review this or answer any questions if you have any
> re: the site or blog -- I think Tim Chen ran into a few issues to update
> for the last release (due to a lack of documentation), and I'd like to
> make sure this is fairly straight-forward for committers moving forward.
>
> Best,
> Dave
>

Updating Mesos website + blog post for 0.22.0 release

[Dave Lester]

Hey Niklas,

Now that 0.22.0 has passed, are you planning to update the Mesos website
and draft a blog post announcement? Any ETA?

I'm happy to help review this or answer any questions if you have any
re: the site or blog -- I think Tim Chen ran into a few issues to update
for the last release (due to a lack of documentation), and I'd like to
make sure this is fairly straight-forward for committers moving forward.

Best,
Dave

Re: Review Request 32426: Symlink the namespace handle with ContainerID for the port mapping isolator.

[Jie Yu]

> On March 24, 2015, 8:01 p.m., Vinod Kone wrote:
> > src/slave/containerizer/isolators/network/port_mapping.cpp, line 1512
> > 
> >
> > Why delete from linkees here? AFAICT, it's not used after this loop.

Yes, but i would rather keep linkers and linkees in sync.


> On March 24, 2015, 8:01 p.m., Vinod Kone wrote:
> > src/slave/containerizer/isolators/network/port_mapping.cpp, line 1813
> > 
> >
> > What happens if the slave dies before doing the symlink?

It's OK because we will not even try to recover that container because veth 
does not exist. MESOS-2547 trackes the removal of stale bind mount handles.


- Jie


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


On March 24, 2015, 2:44 a.m., Jie Yu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32426/
> ---
> 
> (Updated March 24, 2015, 2:44 a.m.)
> 
> 
> Review request for mesos, Chi Zhang, Ian Downes, and Vinod Kone.
> 
> 
> Bugs: MESOS-2528
> https://issues.apache.org/jira/browse/MESOS-2528
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Symlink the namespace handle with ContainerID for the port mapping isolator.
> 
> See ticket for details. This patch will allow a smooth upgrade (i.e., rolling 
> foward and back are both safe).
> 
> 
> Diffs
> -
> 
>   src/slave/containerizer/isolators/network/port_mapping.hpp 
> 4dd066a47d43cb1d52f93294d86309151738743e 
>   src/slave/containerizer/isolators/network/port_mapping.cpp 
> 4bf0adeeac1cb6fe59f9c2ca8d5980b1500f5ddd 
>   src/tests/port_mapping_tests.cpp 8192deac8d9b7ea1896bb62a8b5961ef90326fa4 
> 
> Diff: https://reviews.apache.org/r/32426/diff/
> 
> 
> Testing
> ---
> 
> sudo make check
> 
> Many existing tests should already capture the regression. For example, 
> ROOT_CleanUpOrphanTest checks if the bind mount dir is empty after the 
> container is destroyed.
> 
> Will add a compatibility test tomorrow.
> 
> 
> Thanks,
> 
> Jie Yu
> 
>

Re: [RESULT][VOTE] Release Apache Mesos 0.22.0 (rc4)

[Dick Davies]

Ah ok - config page at
http://mesos.apache.org/documentation/latest/configuration/ gave
me the impression this was an either/or.

I'm happy now, thanks a lot!

On 25 March 2015 at 08:47, Tim Chen  wrote:
> Hi there,
>
> You can already pass in multiple values seperated by comma
> (cgroups/cpu,cgroups/mem,posix/disk)
>
> Tim
>
> On Wed, Mar 25, 2015 at 12:46 AM, Dick Davies 
> wrote:
>>
>> Thanks Craig, that's really handy!
>>
>> Dumb question for the list: are there any plans to support multiple
>> isolation flags somehow?
>> I need cgroups, but would really like the disk quota feature too (and
>> network isolation come to that.
>> And a pony).
>>
>> On 25 March 2015 at 01:00, craig w  wrote:
>> > Congrats, I was working on a quick post summarizing what's new (based on
>> > jira and the video from niklas) which I just posted (great timing)
>> >
>> > http://craigwickesser.com/2015/03/mesos-022-release/
>> >
>> > On Tue, Mar 24, 2015 at 8:30 PM, Paul Otto  wrote:
>> >>
>> >> This is awesome! Thanks for all the hard work you all have put into
>> >> this!
>> >> I am really excited to update to the latest stable version of Apache
>> >> Mesos!
>> >>
>> >> Regards,
>> >> Paul
>> >>
>> >>
>> >> Paul Otto
>> >> Principal DevOps Architect, Co-founder
>> >> Otto Ops LLC | OttoOps.com
>> >> 970.343.4561 office
>> >> 720.381.2383 cell
>> >>
>> >> On Tue, Mar 24, 2015 at 6:04 PM, Niklas Nielsen 
>> >> wrote:
>> >>>
>> >>> Hi all,
>> >>>
>> >>> The vote for Mesos 0.22.0 (rc4) has passed with the
>> >>> following votes.
>> >>>
>> >>> +1 (Binding)
>> >>> --
>> >>> Ben Mahler
>> >>> Tim St Clair
>> >>> Adam Bordelon
>> >>> Brenden Matthews
>> >>>
>> >>> +1 (Non-binding)
>> >>> --
>> >>> Alex Rukletsov
>> >>> Craig W
>> >>> Ben Whitehead
>> >>> Elizabeth Lingg
>> >>> Dario Rexin
>> >>> Jeff Schroeder
>> >>> Michael Park
>> >>> Alexander Rojas
>> >>> Andrew Langhorn
>> >>>
>> >>> There were no 0 or -1 votes.
>> >>>
>> >>> Please find the release at:
>> >>> https://dist.apache.org/repos/dist/release/mesos/0.22.0
>> >>>
>> >>> It is recommended to use a mirror to download the release:
>> >>> http://www.apache.org/dyn/closer.cgi
>> >>>
>> >>> The CHANGELOG for the release is available at:
>> >>>
>> >>>
>> >>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.22.0
>> >>>
>> >>> The mesos-0.22.0.jar has been released to:
>> >>> https://repository.apache.org
>> >>>
>> >>> The website (http://mesos.apache.org) will be updated shortly to
>> >>> reflect
>> >>> this release.
>> >>>
>> >>> Thanks,
>> >>> Niklas
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> >
>> > https://github.com/mindscratch
>> > https://www.google.com/+CraigWickesser
>> > https://twitter.com/mind_scratch
>> > https://twitter.com/craig_links
>
>

Re: [RESULT][VOTE] Release Apache Mesos 0.22.0 (rc4)

[Tim Chen]

Hi there,

You can already pass in multiple values seperated by comma
(cgroups/cpu,cgroups/mem,posix/disk)

Tim

On Wed, Mar 25, 2015 at 12:46 AM, Dick Davies 
wrote:

> Thanks Craig, that's really handy!
>
> Dumb question for the list: are there any plans to support multiple
> isolation flags somehow?
> I need cgroups, but would really like the disk quota feature too (and
> network isolation come to that.
> And a pony).
>
> On 25 March 2015 at 01:00, craig w  wrote:
> > Congrats, I was working on a quick post summarizing what's new (based on
> > jira and the video from niklas) which I just posted (great timing)
> >
> > http://craigwickesser.com/2015/03/mesos-022-release/
> >
> > On Tue, Mar 24, 2015 at 8:30 PM, Paul Otto  wrote:
> >>
> >> This is awesome! Thanks for all the hard work you all have put into
> this!
> >> I am really excited to update to the latest stable version of Apache
> Mesos!
> >>
> >> Regards,
> >> Paul
> >>
> >>
> >> Paul Otto
> >> Principal DevOps Architect, Co-founder
> >> Otto Ops LLC | OttoOps.com
> >> 970.343.4561 office
> >> 720.381.2383 cell
> >>
> >> On Tue, Mar 24, 2015 at 6:04 PM, Niklas Nielsen 
> >> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> The vote for Mesos 0.22.0 (rc4) has passed with the
> >>> following votes.
> >>>
> >>> +1 (Binding)
> >>> --
> >>> Ben Mahler
> >>> Tim St Clair
> >>> Adam Bordelon
> >>> Brenden Matthews
> >>>
> >>> +1 (Non-binding)
> >>> --
> >>> Alex Rukletsov
> >>> Craig W
> >>> Ben Whitehead
> >>> Elizabeth Lingg
> >>> Dario Rexin
> >>> Jeff Schroeder
> >>> Michael Park
> >>> Alexander Rojas
> >>> Andrew Langhorn
> >>>
> >>> There were no 0 or -1 votes.
> >>>
> >>> Please find the release at:
> >>> https://dist.apache.org/repos/dist/release/mesos/0.22.0
> >>>
> >>> It is recommended to use a mirror to download the release:
> >>> http://www.apache.org/dyn/closer.cgi
> >>>
> >>> The CHANGELOG for the release is available at:
> >>>
> >>>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.22.0
> >>>
> >>> The mesos-0.22.0.jar has been released to:
> >>> https://repository.apache.org
> >>>
> >>> The website (http://mesos.apache.org) will be updated shortly to
> reflect
> >>> this release.
> >>>
> >>> Thanks,
> >>> Niklas
> >>
> >>
> >
> >
> >
> > --
> >
> > https://github.com/mindscratch
> > https://www.google.com/+CraigWickesser
> > https://twitter.com/mind_scratch
> > https://twitter.com/craig_links
>

Re: [VOTE] Release Apache Mesos 0.22.0 (rc4)

[Jeff Schroeder]

How does everyone verify each release works? Obviously make check is
important, but are there any sets of automated integration tests that
anyone runs for a new release of mesos? If not, should there be?

On Monday, March 23, 2015, Dario Rexin  wrote:

> +1 (non-binding)
>
> tested with Marathon
>
> On 24 Mar 2015, at 00:03, Adam Bordelon  > wrote:
>
> +1 (binding)
> make check passes on Ubuntu 14.04 and Mac OS X (buildbot)
>
> On Mon, Mar 23, 2015 at 3:44 PM, Elizabeth Lingg  > wrote:
>
>> +1 (Tested with Chronos)
>>
>> -Elizabeth
>>
>> On Mon, Mar 23, 2015 at 3:40 PM, Ben Whitehead <
>> ben.whiteh...@mesosphere.io
>> > wrote:
>>
>>> +1 (non-binding)
>>>
>>> openSUSE 13.2 Linux 3.16.7 / gcc-4.8.3
>>> Tested running Marathon 0.8.1 and Cassandra on Mesos 0.1.0-SNAPSHOT.
>>>
>>>
>>> On Thu, Mar 19, 2015 at 2:18 PM, Alex Rukletsov >> > wrote:
>>>
 +1 (non-binding)

 Mac OS 10.9.5 + clang
 CentOS 7 + gcc 4.4.7 [cgroups tests disabled]

 On Wed, Mar 18, 2015 at 4:04 PM, Brenden Matthews >>> > wrote:

> +1
>
> Tested with internal testing cluster.
>
> On Wed, Mar 18, 2015 at 1:25 PM, craig w  > wrote:
>
>> +1
>>
>> On Wed, Mar 18, 2015 at 3:52 PM, Niklas Nielsen > > wrote:
>>
>>> Hi all,
>>>
>>> Please vote on releasing the following candidate as Apache Mesos
>>> 0.22.0.
>>>
>>>
>>> 0.22.0 includes the following:
>>>
>>> 
>>>
>>> * Support for explicitly sending status updates acknowledgements from
>>>   schedulers; refer to the upgrades document for upgrading
>>> schedulers.
>>> * Rate limiting slave removal, to safeguard against unforeseen bugs
>>> leading to
>>>   widespread slave removal.
>>> * Disk quota isolation in Mesos containerizer; refer to the
>>> containerization
>>>   documentation to enable disk quota monitoring and enforcement.
>>> * Support for module hooks in task launch sequence. Refer to the
>>> modules
>>>   documentation for more information.
>>> * Anonymous modules: a new kind of module that does not receive any
>>> callbacks
>>>   but coexists with its parent process.
>>> * New service discovery info in task info allows framework users to
>>> specify
>>>   discoverability of tasks for external service discovery systems.
>>> Refer to
>>>   the framework development guide for more information.
>>> * New '--external_log_file' flag to serve external logs through the
>>> Mesos web UI.
>>> * New '--gc_disk_headroom' flag to control maxmimum executor sandbox
>>> age.
>>>
>>>
>>> The CHANGELOG for the release is available at:
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.22.0-rc4
>>>
>>> 
>>>
>>> The candidate for Mesos 0.22.0 release is available at:
>>>
>>> https://dist.apache.org/repos/dist/dev/mesos/0.22.0-rc4/mesos-0.22.0.tar.gz
>>>
>>> The tag to be voted on is 0.22.0-rc4:
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.22.0-rc4
>>>
>>> The MD5 checksum of the tarball can be found at:
>>>
>>> https://dist.apache.org/repos/dist/dev/mesos/0.22.0-rc4/mesos-0.22.0.tar.gz.md5
>>>
>>> The signature of the tarball can be found at:
>>>
>>> https://dist.apache.org/repos/dist/dev/mesos/0.22.0-rc4/mesos-0.22.0.tar.gz.asc
>>>
>>> The PGP key used to sign the release is here:
>>> https://dist.apache.org/repos/dist/release/mesos/KEYS
>>>
>>> The JAR is up in Maven in a staging repository here:
>>>
>>> https://repository.apache.org/content/repositories/orgapachemesos-1048
>>>
>>> Please vote on releasing this package as Apache Mesos 0.22.0!
>>>
>>> The vote is open until Sat Mar 21 12:49:56 PDT 2015 and passes if a
>>> majority of at least 3 +1 PMC votes are cast.
>>>
>>> [ ] +1 Release this package as Apache Mesos 0.22.0
>>> [ ] -1 Do not release this package because ...
>>>
>>> Thanks,
>>> Niklas
>>>
>>
>>
>>
>> --
>>
>> https://github.com/mindscratch
>> https://www.google.com/+CraigWickesser
>> https://twitter.com/mind_scratch
>> https://twitter.com/craig_links
>>
>>
>

>>>
>>
>
>

-- 
Text by Jeff, typos by iPhone

Re: [RESULT][VOTE] Release Apache Mesos 0.22.0 (rc4)

[Dick Davies]

Thanks Craig, that's really handy!

Dumb question for the list: are there any plans to support multiple
isolation flags somehow?
I need cgroups, but would really like the disk quota feature too (and
network isolation come to that.
And a pony).

On 25 March 2015 at 01:00, craig w  wrote:
> Congrats, I was working on a quick post summarizing what's new (based on
> jira and the video from niklas) which I just posted (great timing)
>
> http://craigwickesser.com/2015/03/mesos-022-release/
>
> On Tue, Mar 24, 2015 at 8:30 PM, Paul Otto  wrote:
>>
>> This is awesome! Thanks for all the hard work you all have put into this!
>> I am really excited to update to the latest stable version of Apache Mesos!
>>
>> Regards,
>> Paul
>>
>>
>> Paul Otto
>> Principal DevOps Architect, Co-founder
>> Otto Ops LLC | OttoOps.com
>> 970.343.4561 office
>> 720.381.2383 cell
>>
>> On Tue, Mar 24, 2015 at 6:04 PM, Niklas Nielsen 
>> wrote:
>>>
>>> Hi all,
>>>
>>> The vote for Mesos 0.22.0 (rc4) has passed with the
>>> following votes.
>>>
>>> +1 (Binding)
>>> --
>>> Ben Mahler
>>> Tim St Clair
>>> Adam Bordelon
>>> Brenden Matthews
>>>
>>> +1 (Non-binding)
>>> --
>>> Alex Rukletsov
>>> Craig W
>>> Ben Whitehead
>>> Elizabeth Lingg
>>> Dario Rexin
>>> Jeff Schroeder
>>> Michael Park
>>> Alexander Rojas
>>> Andrew Langhorn
>>>
>>> There were no 0 or -1 votes.
>>>
>>> Please find the release at:
>>> https://dist.apache.org/repos/dist/release/mesos/0.22.0
>>>
>>> It is recommended to use a mirror to download the release:
>>> http://www.apache.org/dyn/closer.cgi
>>>
>>> The CHANGELOG for the release is available at:
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.22.0
>>>
>>> The mesos-0.22.0.jar has been released to:
>>> https://repository.apache.org
>>>
>>> The website (http://mesos.apache.org) will be updated shortly to reflect
>>> this release.
>>>
>>> Thanks,
>>> Niklas
>>
>>
>
>
>
> --
>
> https://github.com/mindscratch
> https://www.google.com/+CraigWickesser
> https://twitter.com/mind_scratch
> https://twitter.com/craig_links

Re: Review Request 32149: Enable 'Resources::apply' to handle reservation operations.

[Timothy Chen]

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



src/tests/resources_tests.cpp


How about a test for unreserving?


- Timothy Chen


On March 18, 2015, 5:26 p.m., Michael Park wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32149/
> ---
> 
> (Updated March 18, 2015, 5:26 p.m.)
> 
> 
> Review request for mesos, Alexander Rukletsov, Ben Mahler, and Jie Yu.
> 
> 
> Bugs: MESOS-2477
> https://issues.apache.org/jira/browse/MESOS-2477
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> See summary.
> 
> 
> Diffs
> -
> 
>   src/common/resources.cpp 2c99b6884d7296099e19e2e3182cbe11b5e1e059 
>   src/tests/resources_tests.cpp 7e0ad98c3366f647f190363a0e6b576dbfc7d415 
> 
> Diff: https://reviews.apache.org/r/32149/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Michael Park
> 
>

Re: Review Request 32426: Symlink the namespace handle with ContainerID for the port mapping isolator.

[Jie Yu]

> On March 24, 2015, 8:01 p.m., Vinod Kone wrote:
> > The recovery code is a bit confusing with a bunch of linkers and linkees. 
> > Is it possible to clean that up a bit?
> > 
> > More importantly, IIUC there are 3 entities here. links (veth), pids (file 
> > bind mounted) and containerids (symlink to pid). Why is that there is no 
> > symmetry in their creation (isolate(): pid -> cid -> link) and deletion 
> > (cleanup(): cid -> pid -> link)? Shouldn't 'link' be removed first in 
> > deletion?
> > 
> > Also, have you considered all the cases when a slave fails at any point 
> > during isolate() or cleanup()?
> > 
> > 1) pid, no cid, no link  (slave dies during isolate() or cleanup())
> > 2) pid, cid, no link (slave dies during isolate() or cleanup())
> > 3) pid, cid, link(steady state)
> > 
> > If there is symmetry these are the only cases to consider. If not, there 
> > are more cases to consider.

Yeah, I agree with you. Previously, I want to remove the link in the end so 
that we don't leak a bind mount if slave crashes between veth removal and 
umount. However, as you pointed out, the bind mount will be leaked anyway if 
the slave crashes in isolate() since we create the bind mount first (and we 
must do because we need to have a reference to the namespace handle before 
creating veth, otherwise, it'll be removed automatically if the child process 
exits early).

So I'll swap the deletion order in cleanup() and augument the stale bind mounts 
cleanup (https://issues.apache.org/jira/browse/MESOS-2547).


- Jie


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


On March 24, 2015, 2:44 a.m., Jie Yu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32426/
> ---
> 
> (Updated March 24, 2015, 2:44 a.m.)
> 
> 
> Review request for mesos, Chi Zhang, Ian Downes, and Vinod Kone.
> 
> 
> Bugs: MESOS-2528
> https://issues.apache.org/jira/browse/MESOS-2528
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Symlink the namespace handle with ContainerID for the port mapping isolator.
> 
> See ticket for details. This patch will allow a smooth upgrade (i.e., rolling 
> foward and back are both safe).
> 
> 
> Diffs
> -
> 
>   src/slave/containerizer/isolators/network/port_mapping.hpp 
> 4dd066a47d43cb1d52f93294d86309151738743e 
>   src/slave/containerizer/isolators/network/port_mapping.cpp 
> 4bf0adeeac1cb6fe59f9c2ca8d5980b1500f5ddd 
>   src/tests/port_mapping_tests.cpp 8192deac8d9b7ea1896bb62a8b5961ef90326fa4 
> 
> Diff: https://reviews.apache.org/r/32426/diff/
> 
> 
> Testing
> ---
> 
> sudo make check
> 
> Many existing tests should already capture the regression. For example, 
> ROOT_CleanUpOrphanTest checks if the bind mount dir is empty after the 
> container is destroyed.
> 
> Will add a compatibility test tomorrow.
> 
> 
> Thanks,
> 
> Jie Yu
> 
>

Re: Review Request 32463: Improved testing around state.json endpoints.

[Alexander Rukletsov]

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



src/tests/master_tests.cpp


I noticed you do drive-by clean-up of some `process::` occurrences. Do you 
want to go further and remove all of them or prefer creating a newbie JIRA for 
that? There are e.g. `process::Message` and `Process::Time`.



src/tests/master_tests.cpp


s/ensure/ensures

Not a native speaker, but how about a one liner:
`// This test ensures miscellaneous keys in state.json are present.`



src/tests/master_tests.cpp


AFAIK, we agreed to omit a whitespace between closing angle brackets.



src/tests/master_tests.cpp


Does it make sense to use `Clock::now().secs()` and compare doubles to 
avoid multiple conversions and mimic the way it is actually done in master code?



src/tests/master_tests.cpp


Drop `process::` prefix?



src/tests/master_tests.cpp


This fails on my Mac.

Also, since you're checking start time, you can add one more `EXPECT_GT` 
check caching time before starting master.



src/tests/master_tests.cpp


Why do you check the type here, but not above for e.g. `DATE`, `TIME`, and 
`USER`?



src/tests/master_tests.cpp


How about a one-liner here and below:
```
EXPECT_TRUE(state.values["slaves"].as().values.empty());
```



src/tests/slave_tests.cpp


Not yours, but can you do a drive-by fix and remove `process::`?



src/tests/slave_tests.cpp


Kill `process::` prefix?


- Alexander Rukletsov


On March 24, 2015, 11:42 p.m., Ben Mahler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32463/
> ---
> 
> (Updated March 24, 2015, 11:42 p.m.)
> 
> 
> Review request for mesos, Alexander Rukletsov and Vinod Kone.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This improves the slave test, and adds a new test for the master, to help 
> prevent API regressions.
> 
> 
> Diffs
> -
> 
>   src/tests/master_tests.cpp e69348be676a80017062e3abbd15b8008a6009d7 
>   src/tests/slave_tests.cpp fd09d65bf34136c0959419b451e54105300740c4 
> 
> Diff: https://reviews.apache.org/r/32463/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Ben Mahler
> 
>

Re: Review Request 32405: Fixed the non-POD global variables in port mapping isolator.

[Chi Zhang]

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



src/slave/containerizer/isolators/network/port_mapping.cpp


curious why the const is dropped?


- Chi Zhang


On March 23, 2015, 5:05 p.m., Jie Yu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32405/
> ---
> 
> (Updated March 23, 2015, 5:05 p.m.)
> 
> 
> Review request for mesos, Chi Zhang, Ian Downes, and Vinod Kone.
> 
> 
> Bugs: MESOS-2528
> https://issues.apache.org/jira/browse/MESOS-2528
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Fixed the non-POD global variables in port mapping isolator. We should avoid 
> these non-POD global variables because it's evil during tear down in a 
> multithreaded envorinment.
> 
> I also renamed VETH_PREFIX and BIND_MOUNT_ROOT to be PORT_MAPPING_VETH_PREFIX 
> and PORT_MAPPING_BIND_MOUNT_ROOT because the pid namespace isolator also has 
> BIND_MOUNT_ROOT defined.
> 
> 
> Diffs
> -
> 
>   src/slave/containerizer/isolators/network/port_mapping.hpp 
> 3aae7e264e9496804fd338f805bef31e79e2a153 
>   src/slave/containerizer/isolators/network/port_mapping.cpp 
> 7b4aac88d40e4e5dc3331cb19b647a1d872ef7e2 
>   src/tests/port_mapping_tests.cpp 82f98a47fa374fda13b0be76b07ccc03174a7b96 
> 
> Diff: https://reviews.apache.org/r/32405/diff/
> 
> 
> Testing
> ---
> 
> sudo make check
> 
> 
> Thanks,
> 
> Jie Yu
> 
>

Re: Review Request 32140: Enable 'Resources' to handle 'Resource::ReservationInfo'.

[Timothy Chen]

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



include/mesos/resources.hpp


I'm not sure the following comment adds any value?

"If the optional ReservationInfo is given, the resource's
  // 'reservation' field is set. Otherwise, the resource's
  // 'reservation' field is not set."
  
It sounds like it's just stating the obvious.

What do you think? I think we should just remove it.



src/common/resources.cpp


Why is this check necessary if we're already checking it above?



src/common/resources.cpp


same here



src/common/resources.cpp


same here



src/common/resources.cpp


Why check framework Id? Shouldn't the first 2 checks be enough?



src/common/resources.cpp


As we already checked for * don't have reservation, seems like we should 
just check for has_reservation then?


- Timothy Chen


On March 20, 2015, 10:36 p.m., Michael Park wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32140/
> ---
> 
> (Updated March 20, 2015, 10:36 p.m.)
> 
> 
> Review request for mesos, Alexander Rukletsov, Ben Mahler, and Jie Yu.
> 
> 
> Bugs: MESOS-2476
> https://issues.apache.org/jira/browse/MESOS-2476
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> `Resource::ReservationInfo` was introduced in 
> [r32139](https://reviews.apache.org/r/32139). We need to consider it in our 
> `Resources` class implementation.
> 
> ### `Resources::flatten`
> 
> `flatten` is used as the utility function to cross reservation boundaries 
> without affecting the given resources. Since the reservation is now specified 
> by the (`role`, `reservation`) pair, `flatten` needs to consider 
> `ReservationInfo` as well.
> 
> ### `Resources::validate`
> 
> If `role == "*"`, then `reservation` field must not be set.
> 
> ### `Resources` comparators
> 
> `operator==`, `addable` and `substractable` need to test for 
> `ReservationInfo` as well.
> 
> 
> Diffs
> -
> 
>   include/mesos/resources.hpp 56affd45e1e71e96ff5778b43271f81b9b9a9e4d 
>   src/common/resources.cpp 2c99b6884d7296099e19e2e3182cbe11b5e1e059 
>   src/tests/mesos.hpp 45e35204d1aa876fa0c871acf0f21afcd5ababe8 
>   src/tests/resources_tests.cpp 7e0ad98c3366f647f190363a0e6b576dbfc7d415 
> 
> Diff: https://reviews.apache.org/r/32140/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Michael Park
> 
>

Re: Review Request 30218: Add version() to docker abstraction.

[Timothy Chen]

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



src/docker/docker.cpp


I moved version out to its own future, and still doing the same await in 
line 120.


- Timothy Chen


On Jan. 23, 2015, 5:44 p.m., Timothy Chen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30218/
> ---
> 
> (Updated Jan. 23, 2015, 5:44 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Bernd Mathiske.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Add version() to docker abstraction.
> 
> 
> Diffs
> -
> 
>   src/docker/docker.hpp 3ebbc1f 
>   src/docker/docker.cpp 3a485a2 
> 
> Diff: https://reviews.apache.org/r/30218/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Timothy Chen
> 
>

Re: Review Request 30218: Add version() to docker abstraction.

[Bernd Mathiske]

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



src/docker/docker.cpp


It seems to me that you changed it to indefinite wait.


- Bernd Mathiske


On Jan. 23, 2015, 9:44 a.m., Timothy Chen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30218/
> ---
> 
> (Updated Jan. 23, 2015, 9:44 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Bernd Mathiske.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Add version() to docker abstraction.
> 
> 
> Diffs
> -
> 
>   src/docker/docker.hpp 3ebbc1f 
>   src/docker/docker.cpp 3a485a2 
> 
> Diff: https://reviews.apache.org/r/30218/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Timothy Chen
> 
>

Re: Review Request 29336: Recover docker containers that launched in containers.

[Bernd Mathiske]

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



src/slave/containerizer/docker.cpp


Maybe use the "_" for the parameter, not the local variable? Then both 
local vars "containers" and "executors" look the same in that regard.

However, see the next issue, fixing which would cancel this one.



src/slave/containerizer/docker.cpp


This type/name scheme is hard to understand. How can Docker::Container* 
values be containers and executors? 

How about choosing different variable names that make this more clear? 

It seems that

containers -> logContainers
executors -> executorContainers


- Bernd Mathiske


On Jan. 16, 2015, 5:37 p.m., Timothy Chen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/29336/
> ---
> 
> (Updated Jan. 16, 2015, 5:37 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Bernd Mathiske.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Recover docker containers that launched in containers.
> 
> 
> Diffs
> -
> 
>   src/slave/containerizer/docker.hpp b7bf54a 
>   src/slave/containerizer/docker.cpp 5f4b4ce 
> 
> Diff: https://reviews.apache.org/r/29336/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Timothy Chen
> 
>

Re: Review Request 30931: Added flags to logs at master and slave startup.

[Michael Park]

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


Perhaps a dumb question, but I'm wondering why the enclosing braces belong here 
rather than in `operator << (std::ostream& stream, const FlagsBase& flags)`?

- Michael Park


On March 16, 2015, 3:20 p.m., Joerg Schad wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30931/
> ---
> 
> (Updated March 16, 2015, 3:20 p.m.)
> 
> 
> Review request for mesos and Till Toenshoff.
> 
> 
> Bugs: MESOS-2323
> https://issues.apache.org/jira/browse/MESOS-2323
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Added flags to logs at master and slave startup.
> 
> 
> Diffs
> -
> 
>   src/master/master.cpp dccd7c635da4b7031cd109bd84e7f17b31777ef1 
>   src/slave/slave.cpp 0f99e4efb8fa2b96f120a3e49191158ca0364c06 
> 
> Diff: https://reviews.apache.org/r/30931/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Joerg Schad
> 
>

Re: Review Request 32105: Added << operator to stout.flags.

[Michael Park]

> On March 25, 2015, 3:30 p.m., Michael Park wrote:
> > 3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp, line 597
> > 
> >
> > `s/<<"\""/<< "\""/` in both occurrences.

Also, do we have a rule that we can't use `char` literals? I think `'"'` is 
nicer than `"\""`.


- Michael


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


On March 17, 2015, 12:25 a.m., Joerg Schad wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32105/
> ---
> 
> (Updated March 17, 2015, 12:25 a.m.)
> 
> 
> Review request for mesos.
> 
> 
> Bugs: Mesos-2323
> https://issues.apache.org/jira/browse/Mesos-2323
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> see summary
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp 
> aedb6ab30d929b81f55270612e76009bd7850daa 
> 
> Diff: https://reviews.apache.org/r/32105/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Joerg Schad
> 
>

Re: Review Request 32105: Added << operator to stout.flags.

[Michael Park]

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



3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp


Looks like this fits in 80 columns.



3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp


How about breaking this up in order to avoid the ad-hoc `join` code?

```
std::vector flags;

foreachvalue (const flags::Flags& flag, _flags) {
  const Option& value = flag.stringify(_flags);
  if (value.isSome()) {
flags.push_back(value.get());
  }
}

return stream << join(",", flags);
```



3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp


`s/<<"\""/<< "\""/` in both occurrences.



3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp


Remove empty line


- Michael Park


On March 17, 2015, 12:25 a.m., Joerg Schad wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32105/
> ---
> 
> (Updated March 17, 2015, 12:25 a.m.)
> 
> 
> Review request for mesos.
> 
> 
> Bugs: Mesos-2323
> https://issues.apache.org/jira/browse/Mesos-2323
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> see summary
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp 
> aedb6ab30d929b81f55270612e76009bd7850daa 
> 
> Diff: https://reviews.apache.org/r/32105/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Joerg Schad
> 
>

Re: [VOTE] Release Apache Mesos 0.22.0 (rc4)

[Till Toenshoff]

+1 binding - make check tested on: 
  - OSX 10.10.3 + gcc 4.9.2
  - OSX 10.10.3 + clang 3.5
  - Ubuntu 14.04 + gcc 4.4.7


> On Mar 18, 2015, at 8:52 PM, Niklas Nielsen  wrote:
> 
> Hi all,
> 
> Please vote on releasing the following candidate as Apache Mesos 0.22.0.
> 
> 
> 0.22.0 includes the following:
> 
> 
> * Support for explicitly sending status updates acknowledgements from
>  schedulers; refer to the upgrades document for upgrading schedulers.
> * Rate limiting slave removal, to safeguard against unforeseen bugs leading
> to
>  widespread slave removal.
> * Disk quota isolation in Mesos containerizer; refer to the containerization
>  documentation to enable disk quota monitoring and enforcement.
> * Support for module hooks in task launch sequence. Refer to the modules
>  documentation for more information.
> * Anonymous modules: a new kind of module that does not receive any
> callbacks
>  but coexists with its parent process.
> * New service discovery info in task info allows framework users to specify
>  discoverability of tasks for external service discovery systems. Refer to
>  the framework development guide for more information.
> * New '--external_log_file' flag to serve external logs through the Mesos
> web UI.
> * New '--gc_disk_headroom' flag to control maxmimum executor sandbox age.
> 
> 
> The CHANGELOG for the release is available at:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.22.0-rc4
> 
> 
> The candidate for Mesos 0.22.0 release is available at:
> https://dist.apache.org/repos/dist/dev/mesos/0.22.0-rc4/mesos-0.22.0.tar.gz
> 
> The tag to be voted on is 0.22.0-rc4:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.22.0-rc4
> 
> The MD5 checksum of the tarball can be found at:
> https://dist.apache.org/repos/dist/dev/mesos/0.22.0-rc4/mesos-0.22.0.tar.gz.md5
> 
> The signature of the tarball can be found at:
> https://dist.apache.org/repos/dist/dev/mesos/0.22.0-rc4/mesos-0.22.0.tar.gz.asc
> 
> The PGP key used to sign the release is here:
> https://dist.apache.org/repos/dist/release/mesos/KEYS
> 
> The JAR is up in Maven in a staging repository here:
> https://repository.apache.org/content/repositories/orgapachemesos-1048
> 
> Please vote on releasing this package as Apache Mesos 0.22.0!
> 
> The vote is open until Sat Mar 21 12:49:56 PDT 2015 and passes if a
> majority of at least 3 +1 PMC votes are cast.
> 
> [ ] +1 Release this package as Apache Mesos 0.22.0
> [ ] -1 Do not release this package because ...
> 
> Thanks,
> Niklas

Jenkins build is back to normal : mesos-reviewbot #4801

[Apache Jenkins Server]

See 

Re: Review Request 32198: Added a not equal operator for json objects.

[Michael Park]

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


LGTM!

- Michael Park


On March 23, 2015, 2:19 p.m., Alexander Rojas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32198/
> ---
> 
> (Updated March 23, 2015, 2:19 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Bernd Mathiske, Joerg Schad, 
> Niklas Nielsen, and Till Toenshoff.
> 
> 
> Bugs: MESOS-2510
> https://issues.apache.org/jira/browse/MESOS-2510
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> For consistency, adds a non equal operator to the json objects.
> 
> It also adds tests to the equality operators.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp 
> 334c898906018be6e663f53815abbe047806b95c 
>   3rdparty/libprocess/3rdparty/stout/tests/json_tests.cpp 
> f60d1bbe60f2e2b6460c06bba98e8b85ebb6a3f9 
> 
> Diff: https://reviews.apache.org/r/32198/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Alexander Rojas
> 
>

Re: Review Request 32403: Fixed Alloc/Dealloc mismatch in OsSendfileTest.sendfile.

[Michael Park]

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


LGTM!

- Michael Park


On March 23, 2015, 6:03 p.m., Joerg Schad wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32403/
> ---
> 
> (Updated March 23, 2015, 6:03 p.m.)
> 
> 
> Review request for mesos and Till Toenshoff.
> 
> 
> Bugs: MESOS-2530
> https://issues.apache.org/jira/browse/MESOS-2530
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Fixed Alloc/Dealloc mismatch in OsSendfileTest.sendfile.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/stout/tests/os/sendfile_tests.cpp 
> 2af4dca1559e9edd1e0a4acee9844adacc724a49 
> 
> Diff: https://reviews.apache.org/r/32403/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Joerg Schad
> 
>

Build failed in Jenkins: mesos-reviewbot #4800

[Apache Jenkins Server]

See 

--
[...truncated 5587 lines...]
rm -f Makefile
make[2]: Leaving directory 
`
Making distclean in ec2
make[2]: Entering directory 
`
rm -rf .libs _libs
rm -f *.lo
test -z "" || rm -f 
test . = "../../ec2" || test -z "" || rm -f 
rm -f Makefile
make[2]: Leaving directory 
`
rm -f config.status config.cache config.log configure.lineno 
config.status.lineno
rm -f Makefile
make[1]: Leaving directory 
`
if test -d "mesos-0.23.0"; then find "mesos-0.23.0" -type d ! -perm -200 -exec 
chmod u+w {} ';' && rm -rf "mesos-0.23.0" || { sleep 5 && rm -rf 
"mesos-0.23.0"; }; else :; fi
==
mesos-0.23.0 archives ready for distribution: 
mesos-0.23.0.tar.gz
==

real11m54.372s
user68m19.983s
sys 5m12.670s
+ chmod -R +w 3rdparty aclocal.m4 ar-lib autom4te.cache bin bootstrap CHANGELOG 
compile config.guess config.log config.lt config.status config.sub configure 
configure.ac depcomp Dockerfile docs Doxyfile ec2 frameworks include install-sh 
libtool LICENSE ltmain.sh m4 Makefile Makefile.am Makefile.in 
mesos-0.23.0.tar.gz mesos.pc mesos.pc.in missing mpi NOTICE README.md src 
support
+ git clean -fdx
Removing .gitignore
Removing .libs/
Removing .reviewboardrc
Removing 3rdparty/Makefile
Removing 3rdparty/Makefile.in
Removing 3rdparty/libprocess/.deps/
Removing 3rdparty/libprocess/3rdparty/.deps/
Removing 3rdparty/libprocess/3rdparty/Makefile
Removing 3rdparty/libprocess/3rdparty/Makefile.in
Removing 3rdparty/libprocess/3rdparty/gmock_sources.cc
Removing 3rdparty/libprocess/3rdparty/stout/Makefile
Removing 3rdparty/libprocess/3rdparty/stout/Makefile.in
Removing 3rdparty/libprocess/3rdparty/stout/aclocal.m4
Removing 3rdparty/libprocess/3rdparty/stout/autom4te.cache/
Removing 3rdparty/libprocess/3rdparty/stout/config.log
Removing 3rdparty/libprocess/3rdparty/stout/config.status
Removing 3rdparty/libprocess/3rdparty/stout/configure
Removing 3rdparty/libprocess/3rdparty/stout/include/Makefile
Removing 3rdparty/libprocess/3rdparty/stout/include/Makefile.in
Removing 3rdparty/libprocess/3rdparty/stout/missing
Removing 3rdparty/libprocess/Makefile
Removing 3rdparty/libprocess/Makefile.in
Removing 3rdparty/libprocess/aclocal.m4
Removing 3rdparty/libprocess/ar-lib
Removing 3rdparty/libprocess/autom4te.cache/
Removing 3rdparty/libprocess/compile
Removing 3rdparty/libprocess/config.guess
Removing 3rdparty/libprocess/config.log
Removing 3rdparty/libprocess/config.lt
Removing 3rdparty/libprocess/config.status
Removing 3rdparty/libprocess/config.sub
Removing 3rdparty/libprocess/configure
Removing 3rdparty/libprocess/depcomp
Removing 3rdparty/libprocess/include/Makefile
Removing 3rdparty/libprocess/include/Makefile.in
Removing 3rdparty/libprocess/libtool
Removing 3rdparty/libprocess/ltmain.sh
Removing 3rdparty/libprocess/m4/libtool.m4
Removing 3rdparty/libprocess/m4/ltoptions.m4
Removing 3rdparty/libprocess/m4/ltsugar.m4
Removing 3rdparty/libprocess/m4/ltversion.m4
Removing 3rdparty/libprocess/m4/lt~obsolete.m4
Removing 3rdparty/libprocess/missing
Removing Makefile
Removing Makefile.in
Removing aclocal.m4
Removing ar-lib
Removing autom4te.cache/
Removing bin/gdb-mesos-local.sh
Removing bin/gdb-mesos-master.sh
Removing bin/gdb-mesos-slave.sh
Removing bin/gdb-mesos-tests.sh
Removing bin/lldb-mesos-local.sh
Removing bin/lldb-mesos-master.sh
Removing bin/lldb-mesos-slave.sh
Removing bin/lldb-mesos-tests.sh
Removing bin/mesos-local-flags.sh
Removing bin/mesos-local.sh
Removing bin/mesos-master-flags.sh
Removing bin/mesos-master.sh
Removing bin/mesos-slave-flags.sh
Removing bin/mesos-slave.sh
Removing bin/mesos-tests-flags.sh
Removing bin/mesos-tests.sh
Removing bin/mesos.sh
Removing bin/valgrind-mesos-local.sh
Removing bin/valgrind-mesos-master.sh
Removing bin/valgrind-mesos-slave.sh
Removing bin/valgrind-mesos-tests.sh
Removing compile
Removing config.guess
Removing config.log
Removing config.lt
Removing config.status
Removing config.sub
Removing configure
Removing depcomp
Removing ec2/Makefile
Removing ec2/Makefile.in
Removing include/mesos/version.hpp
Removing install-sh
Removing libtool
Removing ltmain.sh
Removing m4/libtool.m4
Removing m4/ltoptions.m4
Removing m4/ltsugar.m4
Removing m4/ltversion.m4
Removing m4/lt~obsolete.m4
Removing mesos-0.23.0.tar.gz
Removing mesos.pc
Removing missing
Removing mpi/mpiexec-mesos
Removing src/.deps/
Removing src/Makefile
Removing src/Makefile.in
Removing src/authentication/.deps/
Removing src/authentication/cram_md5/.deps/
Removing src/authorizer/.deps/
Removing src/cli/.deps/
Removing src/common/.deps/
Removing src/contain

Re: Review Request 30612: Added /master/frameworks/{framework}/tasks/{task} endpoint.

[Alexander Rojas]

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

(Updated March 25, 2015, 2:06 p.m.)


Review request for mesos, Ben Mahler, Niklas Nielsen, and Till Toenshoff.


Bugs: MESOS-2157
https://issues.apache.org/jira/browse/MESOS-2157


Repository: mesos


Description (updated)
---

Adds endpoints for paths /master/frameworks/{framework}/tasks/{task}.

Adds tests for the endpoints.

Works with [29883](https://reviews.apache.org/r/29883).

Builds on the abandoned patch 14286.


Diffs
-

  src/master/http.cpp e1a87d646e9690e39a9e84ae383622018ce80401 
  src/master/master.hpp 3c957abcb54a0c23b8549c1d21d2d9277791938d 
  src/master/master.cpp dccd7c635da4b7031cd109bd84e7f17b31777ef1 
  src/tests/master_tests.cpp e69348be676a80017062e3abbd15b8008a6009d7 

Diff: https://reviews.apache.org/r/30612/diff/


Testing
---

make check


Thanks,

Alexander Rojas

Re: Review Request 32198: Added a not equal operator for json objects.

[Till Toenshoff]

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

Ship it!


Ship It!

- Till Toenshoff


On March 23, 2015, 2:19 p.m., Alexander Rojas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32198/
> ---
> 
> (Updated March 23, 2015, 2:19 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Bernd Mathiske, Joerg Schad, 
> Niklas Nielsen, and Till Toenshoff.
> 
> 
> Bugs: MESOS-2510
> https://issues.apache.org/jira/browse/MESOS-2510
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> For consistency, adds a non equal operator to the json objects.
> 
> It also adds tests to the equality operators.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp 
> 334c898906018be6e663f53815abbe047806b95c 
>   3rdparty/libprocess/3rdparty/stout/tests/json_tests.cpp 
> f60d1bbe60f2e2b6460c06bba98e8b85ebb6a3f9 
> 
> Diff: https://reviews.apache.org/r/32198/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Alexander Rojas
> 
>

Re: Review Request 32198: Added a not equal operator for json objects.

[Till Toenshoff]

> On March 18, 2015, 5:36 p.m., Till Toenshoff wrote:
> > 3rdparty/libprocess/3rdparty/stout/tests/json_tests.cpp, lines 252-263
> > 
> >
> > Right now, these tests appear a bit random to me. Can you explain the 
> > idea on why you came up with 8 tests?
> > 
> > Maybe we could have some simple top-level object comparison first 
> > `{"foo": "foo"} != {"bar": "bar"}` to be more explicit. Then one or two 
> > deeper nested variants?
> 
> Alexander Rojas wrote:
> It is not random, it just has one element of each type you can have as a 
> json, an array, a boolean, a null a string and a nested object. It just 
> ensures that the visitor will call all of its methods in turn.

Thanks for clarifying.


- Till


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


On March 23, 2015, 2:19 p.m., Alexander Rojas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32198/
> ---
> 
> (Updated March 23, 2015, 2:19 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Bernd Mathiske, Joerg Schad, 
> Niklas Nielsen, and Till Toenshoff.
> 
> 
> Bugs: MESOS-2510
> https://issues.apache.org/jira/browse/MESOS-2510
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> For consistency, adds a non equal operator to the json objects.
> 
> It also adds tests to the equality operators.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp 
> 334c898906018be6e663f53815abbe047806b95c 
>   3rdparty/libprocess/3rdparty/stout/tests/json_tests.cpp 
> f60d1bbe60f2e2b6460c06bba98e8b85ebb6a3f9 
> 
> Diff: https://reviews.apache.org/r/32198/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Alexander Rojas
> 
>

Re: Review Request 30931: Added flags to logs at master and slave startup.

[Till Toenshoff]

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

Ship it!


Ship It!

- Till Toenshoff


On March 16, 2015, 3:20 p.m., Joerg Schad wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30931/
> ---
> 
> (Updated March 16, 2015, 3:20 p.m.)
> 
> 
> Review request for mesos and Till Toenshoff.
> 
> 
> Bugs: MESOS-2323
> https://issues.apache.org/jira/browse/MESOS-2323
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Added flags to logs at master and slave startup.
> 
> 
> Diffs
> -
> 
>   src/master/master.cpp dccd7c635da4b7031cd109bd84e7f17b31777ef1 
>   src/slave/slave.cpp 0f99e4efb8fa2b96f120a3e49191158ca0364c06 
> 
> Diff: https://reviews.apache.org/r/30931/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Joerg Schad
> 
>

Re: Review Request 32105: Added << operator to stout.flags.

[Till Toenshoff]

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

Ship it!


Ship It!

- Till Toenshoff


On March 17, 2015, 12:25 a.m., Joerg Schad wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32105/
> ---
> 
> (Updated March 17, 2015, 12:25 a.m.)
> 
> 
> Review request for mesos.
> 
> 
> Bugs: Mesos-2323
> https://issues.apache.org/jira/browse/Mesos-2323
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> see summary
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp 
> aedb6ab30d929b81f55270612e76009bd7850daa 
> 
> Diff: https://reviews.apache.org/r/32105/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Joerg Schad
> 
>

Re: Review Request 32403: Fixed Alloc/Dealloc mismatch in OsSendfileTest.sendfile.

[Till Toenshoff]

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

Ship it!


Ship It!

- Till Toenshoff


On March 23, 2015, 6:03 p.m., Joerg Schad wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32403/
> ---
> 
> (Updated March 23, 2015, 6:03 p.m.)
> 
> 
> Review request for mesos and Till Toenshoff.
> 
> 
> Bugs: MESOS-2530
> https://issues.apache.org/jira/browse/MESOS-2530
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Fixed Alloc/Dealloc mismatch in OsSendfileTest.sendfile.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/stout/tests/os/sendfile_tests.cpp 
> 2af4dca1559e9edd1e0a4acee9844adacc724a49 
> 
> Diff: https://reviews.apache.org/r/32403/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Joerg Schad
> 
>

Re: Review Request 31538: Added validations performed in the MesosExecutorDriver to the Slave.

[Till Toenshoff]

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

Ship it!


Ship It!

- Till Toenshoff


On March 9, 2015, 11:09 a.m., Alexander Rojas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31538/
> ---
> 
> (Updated March 9, 2015, 11:09 a.m.)
> 
> 
> Review request for mesos, Isabel Jimenez, Till Toenshoff, and Vinod Kone.
> 
> 
> Bugs: mesos-2291
> https://issues.apache.org/jira/browse/mesos-2291
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Copies validations made to the messages exchanged between the slave and the 
> `MesosExecutorDriver` and performed in the executor driver to the slave. This 
> is requiered since the new HTTP API will deprecate the executor driver.
> 
> 
> Diffs
> -
> 
>   src/exec/exec.cpp d678f0682d803b0b080c3a6c296067ac9ab5dbf8 
>   src/slave/slave.cpp 364d911b086dfe1f15f76aa3888f99146aa8d876 
> 
> Diff: https://reviews.apache.org/r/31538/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Alexander Rojas
> 
>

Re: Review Request 31985: Mesos container ID available to the executor through an environment variable.

[Alexander Rojas]

> On March 14, 2015, 1:49 a.m., Timothy Chen wrote:
> > The change looks good, but I'm not sure how exposing the container id is 
> > the right thing to do overall yet. Container id as I know of is meant to be 
> > a internal id that is used only in mesos, and I believe the whole 
> > motivation was for users to be able to guess the docker container name from 
> > the container id. However, container id -> docker container name mapping 
> > might change since we manage that, and I'm progress changing it to include 
> > the slave id.
> > 
> > I personally think we should think about exposing container specific 
> > information.
> > 
> > Do you know if there is any other use case to know the container id?
> 
> Alexander Rojas wrote:
> 1. I am not aware of any other use case. However I asked benh about this 
> and he mentioned it was ok to have this as extra info on the update, as long 
> as it was no docker specific data.
> 2. After asking some questions to the original reporter, the idea was 
> more to be able to group tasks assigned to the same container, but not as a 
> way to extract the specific container.
> 3. I am not sure, then, what would be considered mesos private info and 
> info which can be shared. For example, why can the framework id and the 
> executor id be shared but no the container id?
> 
> Vinod Kone wrote:
> "group tasks assigned to the same container " .. What does this mean? 
> IIUC, our docker containerizer only supports single task containers.
> 
> regarding why framework id and executor id are exposed: framework id is 
> needed by frameworks to reregister with master. executor id (and task id) is 
> generated by the framework and not mesos.
> 
> Alexander Rojas wrote:
> So I guess then, I will discard this patch and set the issue to won't fix?
> 
> Vinod Kone wrote:
> I think we should try to understand the root of the issue that the 
> reporter is having before jumping onto a specific implementation.
> 
> Alexander Rojas wrote:
> Well, I felt like I had it clear but apparently not. Can you please ask 
> the questions in the Jira entry vinod?
> 
> I was also wondering, As mentioned above, we want to keep the 
> `containerId` private within mesos, but patch 
> [32426](https://reviews.apache.org/r/32426) effectively makes it public.
> 
> Alexander Rojas wrote:
> I got it now… it is still quite private. Forget my question on the second 
> paragraph.

One more thing Vinod, you wrote one container per task, however if you check 
the code (Slave.cpp at `Executor* Framework::launchExecutor(ExecutorInfo&, 
TaskInfo&)`) what we have is one container per executor.


- Alexander


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


On March 20, 2015, 10:27 a.m., Alexander Rojas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31985/
> ---
> 
> (Updated March 20, 2015, 10:27 a.m.)
> 
> 
> Review request for mesos, Bernd Mathiske, Isabel Jimenez, Joerg Schad, Till 
> Toenshoff, and Vinod Kone.
> 
> 
> Bugs: MESOS-2191
> https://issues.apache.org/jira/browse/MESOS-2191
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> When the executor is created, the container ID where it runs is made 
> accesible through an environment variable.
> 
> 
> Diffs
> -
> 
>   src/exec/exec.cpp d678f0682d803b0b080c3a6c296067ac9ab5dbf8 
>   src/slave/containerizer/containerizer.hpp 
> 129e60f20835f5d151701e934330b81825887af1 
>   src/slave/containerizer/containerizer.cpp 
> 4d66e767de1f877cb66b37826ba7c9d00639a7c0 
>   src/slave/containerizer/docker.hpp b7bf54ac65d6c61622e485ac253513eaac2e4f88 
>   src/slave/containerizer/docker.cpp 5f4b4ce49a9523e4743e5c79da4050e6f9e29ed7 
>   src/slave/containerizer/external_containerizer.cpp 
> 42c67f548caf7bddbe131e0dfa7d74227d8c2593 
>   src/slave/containerizer/mesos/containerizer.cpp 
> fbd1c0a0e5f4f227adb022f0baaa6d2c7e3ad748 
>   src/tests/containerizer.cpp 26b87ac6b16dfeaf84888e80296ef540697bd775 
>   src/tests/slave_tests.cpp a975305430097a8295b4b155e8448572c12bde22 
> 
> Diff: https://reviews.apache.org/r/31985/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Alexander Rojas
> 
>