Re: master and slave talking but not showing up in ui

[Jason Giedymin]

Also check out https://github.com/JasonGiedymin/ansible-mesos

-Jason

> On Feb 21, 2014, at 11:48 PM, Joe Stein  wrote:
> 
> No, I was not getting register with master.  I set the --ip= and it is
> working fine now :)
> 
> Thanks!
> 
> /***
> Joe Stein
> Founder, Principal Consultant
> Big Data Open Source Security LLC
> http://www.stealth.ly
> Twitter: @allthingshadoop 
> /
> 
> 
>> On Fri, Feb 21, 2014 at 11:55 AM, Ross Allen  wrote:
>> 
>> Joe, do you ever get a line in your slave output that mentions registering
>> with the master? The output you pasted doesn't show that happening. The
>> lines should look something like this (bold added by me):
>> 
>> I0221 10:20:13.964689 230219776 slave.cpp:501] New master detected at
>> master@192.168.1.115:5050
>> 
>> I0221 10:20:13.964833 228073472 status_update_manager.cpp:162] New master
>> detected at master@192.168.1.115:5050
>> 
>> I0221 10:20:13.964891 230219776 slave.cpp:526] Detecting new master
>> 
>> *I0221 10:20:13.965553 227000320 slave.cpp:544] Registered with master
>> master@192.168.1.115:5050 ; given slave
>> ID 201402211020-1929488576-5050-59729-0*
>> 
>> Ross Allen
>> r...@mesosphere.io
>> 
>> 
>>> On 21 February 2014 01:52, Joe Stein  wrote:
>>> 
>>> from master
>>> 
>>> root@oss001:/home/jstein# /usr/local/sbin/mesos-master --zk=zk://
>>> 138.113.121.10:2181,/etc
>>> I0221 00:49:22.075003 17646 main.cpp:126] Build: 2014-02-06 19:32:44 by
>>> root
>>> I0221 00:49:22.075582 17646 main.cpp:167] Starting Mesos master
>>> I0221 00:49:22.075772 17650 master.cpp:283] Master started on
>>> 138.138.138.10:5050
>>> I0221 00:49:22.075848 17650 master.cpp:297] Master ID:
>>> 201402210049-176851594-5050-17646
>>> I0221 00:49:22.075932 17650 master.cpp:307] Master allowing
>> unauthenticated
>>> frameworks to register!!
>>> 2014-02-21 00:49:22,076:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@658:
>> Client
>>> environment:zookeeper.version=zookeeper C client 3.3.4
>>> 2014-02-21 00:49:22,076:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@662:
>> Client
>>> environment:host.name=oss001
>>> 2014-02-21 00:49:22,076:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@669:
>> Client
>>> environment:os.name=Linux
>>> 2014-02-21 00:49:22,076:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@670:
>> Client
>>> environment:os.arch=3.8.0-29-generic
>>> 2014-02-21 00:49:22,076:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@671:
>> Client
>>> environment:os.version=#42~precise1-Ubuntu SMP Wed Aug 14 16:19:23 UTC
>> 2013
>>> 2014-02-21 00:49:22,076:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@658:
>> Client
>>> environment:zookeeper.version=zookeeper C client 3.3.4
>>> 2014-02-21 00:49:22,076:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@662:
>> Client
>>> environment:host.name=oss001
>>> 2014-02-21 00:49:22,076:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@669:
>> Client
>>> environment:os.name=Linux
>>> 2014-02-21 00:49:22,076:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@670:
>> Client
>>> environment:os.arch=3.8.0-29-generic
>>> 2014-02-21 00:49:22,076:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@671:
>> Client
>>> environment:os.version=#42~precise1-Ubuntu SMP Wed Aug 14 16:19:23 UTC
>> 2013
>>> I0221 00:49:22.078568 17649 contender.cpp:121] Joining the ZK group with
>>> data: 'master@138.138.138.10:5050'
>>> 2014-02-21 00:49:22,106:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@679:
>> Client
>>> environment:user.name=jstein
>>> 2014-02-21 00:49:22,106:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@687:
>> Client
>>> environment:user.home=/root
>>> 2014-02-21 00:49:22,106:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@699:
>> Client
>>> environment:user.dir=/home/jstein
>>> 2014-02-21 00:49:22,106:17646(0x7fbf0e3e4700):ZOO_INFO@zookeeper_init
>> @727:
>>> Initiating client connection, host=138.113.121.10:2181,
>>> sessionTimeout=1 watcher=0x7fbf18045e60 sessionId=0
>>> sessionPasswd= context=0x7fbeff90 flags=0
>>> 2014-02-21 00:49:22,106:17646(0x7fbef700):ZOO_INFO@check_events
>> @1585:
>>> initiated connection to server [138.113.121.10:2181]
>>> 2014-02-21 00:49:22,108:17646(0x7fbef700):ZOO_INFO@check_events
>> @1632:
>>> session establishment complete on server [138.113.121.10:2181],
>>> sessionId=0x14452bb562c0017, negotiated timeout=1
>>> I0221 00:49:22.109210 17648 group.cpp:310] Group process ((5)@
>>> 138.138.138.10:5050) connected to ZooKeeper
>>> I0221 00:49:22.109261 17648 group.cpp:752] Syncing group operations:
>> queue
>>> size (joins, cancels, datas) = (0, 0, 0)
>>> I0221 00:49:22.109295 17648 group.cpp:367] Trying to create path '/etc'
>> in
>>> ZooKeeper
>>> 2014-02-21 00:49:22,132:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@679:
>> Client
>>> environment:user.name=jstein
>>> 2014-02-21 00:49:22,132:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@687:
>> Client
>>> environment:user.home=/root
>>> 2014-02-21 00:49:22,132:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@699:
>> Client
>>> environmen

Re: master and slave talking but not showing up in ui

[Joe Stein]

No, I was not getting register with master.  I set the --ip= and it is
working fine now :)

Thanks!

/***
 Joe Stein
 Founder, Principal Consultant
 Big Data Open Source Security LLC
 http://www.stealth.ly
 Twitter: @allthingshadoop 
/


On Fri, Feb 21, 2014 at 11:55 AM, Ross Allen  wrote:

> Joe, do you ever get a line in your slave output that mentions registering
> with the master? The output you pasted doesn't show that happening. The
> lines should look something like this (bold added by me):
>
> I0221 10:20:13.964689 230219776 slave.cpp:501] New master detected at
> master@192.168.1.115:5050
>
> I0221 10:20:13.964833 228073472 status_update_manager.cpp:162] New master
> detected at master@192.168.1.115:5050
>
> I0221 10:20:13.964891 230219776 slave.cpp:526] Detecting new master
>
> *I0221 10:20:13.965553 227000320 slave.cpp:544] Registered with master
> master@192.168.1.115:5050 ; given slave
> ID 201402211020-1929488576-5050-59729-0*
>
> Ross Allen
> r...@mesosphere.io
>
>
> On 21 February 2014 01:52, Joe Stein  wrote:
>
> > from master
> >
> > root@oss001:/home/jstein# /usr/local/sbin/mesos-master --zk=zk://
> > 138.113.121.10:2181,/etc
> > I0221 00:49:22.075003 17646 main.cpp:126] Build: 2014-02-06 19:32:44 by
> > root
> > I0221 00:49:22.075582 17646 main.cpp:167] Starting Mesos master
> > I0221 00:49:22.075772 17650 master.cpp:283] Master started on
> > 138.138.138.10:5050
> > I0221 00:49:22.075848 17650 master.cpp:297] Master ID:
> > 201402210049-176851594-5050-17646
> > I0221 00:49:22.075932 17650 master.cpp:307] Master allowing
> unauthenticated
> > frameworks to register!!
> > 2014-02-21 00:49:22,076:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@658:
> Client
> > environment:zookeeper.version=zookeeper C client 3.3.4
> > 2014-02-21 00:49:22,076:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@662:
> Client
> > environment:host.name=oss001
> > 2014-02-21 00:49:22,076:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@669:
> Client
> > environment:os.name=Linux
> > 2014-02-21 00:49:22,076:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@670:
> Client
> > environment:os.arch=3.8.0-29-generic
> > 2014-02-21 00:49:22,076:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@671:
> Client
> > environment:os.version=#42~precise1-Ubuntu SMP Wed Aug 14 16:19:23 UTC
> 2013
> > 2014-02-21 00:49:22,076:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@658:
> Client
> > environment:zookeeper.version=zookeeper C client 3.3.4
> > 2014-02-21 00:49:22,076:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@662:
> Client
> > environment:host.name=oss001
> > 2014-02-21 00:49:22,076:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@669:
> Client
> > environment:os.name=Linux
> > 2014-02-21 00:49:22,076:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@670:
> Client
> > environment:os.arch=3.8.0-29-generic
> > 2014-02-21 00:49:22,076:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@671:
> Client
> > environment:os.version=#42~precise1-Ubuntu SMP Wed Aug 14 16:19:23 UTC
> 2013
> > I0221 00:49:22.078568 17649 contender.cpp:121] Joining the ZK group with
> > data: 'master@138.138.138.10:5050'
> > 2014-02-21 00:49:22,106:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@679:
> Client
> > environment:user.name=jstein
> > 2014-02-21 00:49:22,106:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@687:
> Client
> > environment:user.home=/root
> > 2014-02-21 00:49:22,106:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@699:
> Client
> > environment:user.dir=/home/jstein
> > 2014-02-21 00:49:22,106:17646(0x7fbf0e3e4700):ZOO_INFO@zookeeper_init
> @727:
> > Initiating client connection, host=138.113.121.10:2181,
> > sessionTimeout=1 watcher=0x7fbf18045e60 sessionId=0
> > sessionPasswd= context=0x7fbeff90 flags=0
> > 2014-02-21 00:49:22,106:17646(0x7fbef700):ZOO_INFO@check_events
> @1585:
> > initiated connection to server [138.113.121.10:2181]
> > 2014-02-21 00:49:22,108:17646(0x7fbef700):ZOO_INFO@check_events
> @1632:
> > session establishment complete on server [138.113.121.10:2181],
> > sessionId=0x14452bb562c0017, negotiated timeout=1
> > I0221 00:49:22.109210 17648 group.cpp:310] Group process ((5)@
> > 138.138.138.10:5050) connected to ZooKeeper
> > I0221 00:49:22.109261 17648 group.cpp:752] Syncing group operations:
> queue
> > size (joins, cancels, datas) = (0, 0, 0)
> > I0221 00:49:22.109295 17648 group.cpp:367] Trying to create path '/etc'
> in
> > ZooKeeper
> > 2014-02-21 00:49:22,132:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@679:
> Client
> > environment:user.name=jstein
> > 2014-02-21 00:49:22,132:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@687:
> Client
> > environment:user.home=/root
> > 2014-02-21 00:49:22,132:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@699:
> Client
> > environment:user.dir=/home/jstein
> > 2014-02-21 00:49:22,132:17646(0x7fbf0f3e6700):ZOO_INFO@zookeeper_init
> @727:
> > Initiating client connection, host=138.113.121.10:2181,
> > sessionTimeout=1 watcher=0x7fbf18045

Re: Review Request 18249: Removed 'using namespace process' from header files.

[Dominic Hamon]

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

(Updated Feb. 21, 2014, 5:22 p.m.)


Review request for mesos, Benjamin Hindman, Ben Mahler, and Vinod Kone.


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


Repository: mesos-git


Description
---

See summary


Diffs (updated)
-

  src/master/hierarchical_allocator_process.hpp 
96b6ad569ea3758e4d078c6b2d60da4ea4fe8693 
  src/master/http.cpp 6654cac1b5e33f548a555ee516b3823dfb2f854e 
  src/master/master.hpp 768dc3d165510d9e65e4b44075256b2805fde18c 
  src/master/master.cpp de40884f873656cf91566ef49736cb8dda1300d8 
  src/slave/http.cpp 7ed9abe704b852c0237886ad59ff94b31ac4fb24 
  src/slave/slave.hpp d82d4e9547fc8c44f2210e1fafec766c381ab35c 
  src/slave/slave.cpp 7ad823244eb8e9a2bc3899bdf728a5faed4eafbd 
  src/slave/status_update_manager.hpp d29e269b00de0fc63d6281976f5efe1218ba9ba9 
  src/slave/status_update_manager.cpp a88bb183b5122ff5adc59a0e6e697f7f9b2a3945 

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


Testing
---

no functional change expected.

built. ran make check.


Thanks,

Dominic Hamon

[jira] [Commented] (MESOS-990) Merge JSON model code into common

[Dominic Hamon (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13909106#comment-13909106
 ] 

Dominic Hamon commented on MESOS-990:
-

Fixed in: https://reviews.apache.org/r/18144/

tests still required, but are pending good stringify support.

> Merge JSON model code into common
> -
>
> Key: MESOS-990
> URL: https://issues.apache.org/jira/browse/MESOS-990
> Project: Mesos
>  Issue Type: Improvement
>  Components: master, slave
>Reporter: Dominic Hamon
>Assignee: Dominic Hamon
>Priority: Minor
> Fix For: 0.19.0
>
>
> Much of the model code in src/master/http.cpp and src/slave/http.cpp should 
> be in common.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: Review Request 18311: Adds await on a tuple of futures.

[Adam B]

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



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


Since both use stout/tuple.hpp now, is there much difference in the c++11 
implementation besides the actual lambda statements?
Finer-grained #if's could reduce the amount of duplicated code, at the 
expense of more #if's.


- Adam B


On Feb. 21, 2014, 5:05 p.m., TILL TOENSHOFF wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18311/
> ---
> 
> (Updated Feb. 21, 2014, 5:05 p.m.)
> 
> 
> Review request for mesos, Adam B, Benjamin Hindman, Ben Mahler, Niklas 
> Nielsen, and Vinod Kone.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Currently the Process::await implementation on list, by the nature of 
> std::list, expects equally typed futures. This new override implements await 
> for a tuple of futures, hence allows awaiting differently typed futures in a 
> single call.
> 
> There also is a new override that allows await on a single Future, a 
> convenience approach for allowing a Process based await on a single Future 
> without forcing the user to render a list or tuple out of that. 
> 
> A C++11 and a boost-based implementation have been added.
> 
> This patch also includes tests on those new overrides.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/include/process/c++11/collect.hpp PRE-CREATION 
>   3rdparty/libprocess/include/process/collect.hpp 2a73bc9 
>   3rdparty/libprocess/src/tests/process_tests.cpp e899aed 
> 
> Diff: https://reviews.apache.org/r/18311/diff/
> 
> 
> Testing
> ---
> 
> make check (clang c++11, gcc)
> 
> 
> Thanks,
> 
> TILL TOENSHOFF
> 
>

[jira] [Commented] (MESOS-692) reservations are reported incorrectly in master's state.json

[Dominic Hamon (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13909103#comment-13909103
 ] 

Dominic Hamon commented on MESOS-692:
-

Fixed in https://reviews.apache.org/r/18144/

> reservations are reported incorrectly in master's state.json
> 
>
> Key: MESOS-692
> URL: https://issues.apache.org/jira/browse/MESOS-692
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Reporter: brian wickman
>Assignee: Dominic Hamon
>  Labels: newbie
> Fix For: 0.19.0
>
>
> When you dump state.json from the master, it lists out a single resources 
> dict, e.g.
> {noformat}
> >>> state['slaves'][0]
> {..., u'registered_time': 1378851991.87182, u'reregistered_time': 
> 1378917907.3190701, u'id': u'201309042122-193162-5050-55755-120', 
> u'resources': {u'mem': 21913, u'disk': 40, u'cpus': 14, u'ports': 
> u'[31000-32000]'}}
> {noformat}
> Looking at the code, it looks like last value wins:
> {noformat}
> // Returns a JSON object modeled on a Resources.
> JSON::Object model(const Resources& resources)
> {
>   JSON::Object object;
>   foreach (const Resource& resource, resources) {
> switch (resource.type()) {
>   case Value::SCALAR:
> object.values[resource.name()] = resource.scalar().value();
> break;
>   case Value::RANGES:
> object.values[resource.name()] = stringify(resource.ranges());
> break;
>   case Value::SET:
> object.values[resource.name()] = stringify(resource.set());
> break;
>   default:
> LOG(FATAL) << "Unexpected Value type: " << resource.type();
> break;
> }
>   }
>   return object;
> }
> {noformat}
> So for example if you had role * with 15 cores and role "hdfs" with 1 cores, 
> the resource dict might just report 1 core.  Instead it should probably 
> aggregate resources by role, and have resources = {'*': {ram, cpu, disk}, 
> 'hdfs': {ram, cpu, disk}} etc.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (MESOS-692) reservations are reported incorrectly in master's state.json

[Dominic Hamon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dominic Hamon resolved MESOS-692.
-

   Resolution: Fixed
Fix Version/s: 0.19.0

> reservations are reported incorrectly in master's state.json
> 
>
> Key: MESOS-692
> URL: https://issues.apache.org/jira/browse/MESOS-692
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Reporter: brian wickman
>Assignee: Dominic Hamon
>  Labels: newbie
> Fix For: 0.19.0
>
>
> When you dump state.json from the master, it lists out a single resources 
> dict, e.g.
> {noformat}
> >>> state['slaves'][0]
> {..., u'registered_time': 1378851991.87182, u'reregistered_time': 
> 1378917907.3190701, u'id': u'201309042122-193162-5050-55755-120', 
> u'resources': {u'mem': 21913, u'disk': 40, u'cpus': 14, u'ports': 
> u'[31000-32000]'}}
> {noformat}
> Looking at the code, it looks like last value wins:
> {noformat}
> // Returns a JSON object modeled on a Resources.
> JSON::Object model(const Resources& resources)
> {
>   JSON::Object object;
>   foreach (const Resource& resource, resources) {
> switch (resource.type()) {
>   case Value::SCALAR:
> object.values[resource.name()] = resource.scalar().value();
> break;
>   case Value::RANGES:
> object.values[resource.name()] = stringify(resource.ranges());
> break;
>   case Value::SET:
> object.values[resource.name()] = stringify(resource.set());
> break;
>   default:
> LOG(FATAL) << "Unexpected Value type: " << resource.type();
> break;
> }
>   }
>   return object;
> }
> {noformat}
> So for example if you had role * with 15 cores and role "hdfs" with 1 cores, 
> the resource dict might just report 1 core.  Instead it should probably 
> aggregate resources by role, and have resources = {'*': {ram, cpu, disk}, 
> 'hdfs': {ram, cpu, disk}} etc.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (MESOS-1023) Replace all static/global variables with non-POD type

[Dominic Hamon (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13909101#comment-13909101
 ] 

Dominic Hamon commented on MESOS-1023:
--

Some implementation: https://reviews.apache.org/r/18321/

> Replace all static/global variables with non-POD type
> -
>
> Key: MESOS-1023
> URL: https://issues.apache.org/jira/browse/MESOS-1023
> Project: Mesos
>  Issue Type: Bug
>  Components: general
>Reporter: Dominic Hamon
>Assignee: Dominic Hamon
>  Labels: c++
> Fix For: 0.19.0
>
>
> See 
> http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Static_and_Global_Variables
>  for the background.
> Real bugs have been seen. For example, in process::ID::generate we have a 
> map that can be accessed within the function after exit has been 
> called. Ie, we can try to access the map after it's been destroyed, but 
> before exit has completed.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: Review Request 18311: Adds await on a tuple of futures.

[TILL TOENSHOFF]

> On Feb. 20, 2014, 4:37 p.m., Dominic Hamon wrote:
> > 3rdparty/libprocess/include/process/collect.hpp, line 2
> > 
> >
> > possibly naive question: instead of having a full copy of this header 
> > with the type changed, would it be possible to just typedef 
> > 'process::tuple' or add a 'stout::tuple' that is either a 
> > boost::tuples::tuple or std::tuple?
> 
> TILL TOENSHOFF wrote:
> There is a point in what you say, but it wont fix things entirely.
> 
> The C++11 implementation makes use of "proper" lambdas, the other 
> implementation does not but emulates those by the use of _await and _then.
> 
> However, pulling boost::tupes::tuple or std::tuple into the libprocess 
> namespace depending on the availability is a good idea (unless it clashes at 
> a point I dont see right now). I will suggest another RR and adapt this one 
> to make use of this once that is done.

I made this RR dependent on 18360 to allow for having a unified 
tuple-definition.

To entirely "fix" what you aimed for, the collect-header would have to be 
sprinkled with a bunch of #if-#else's which I hesitated to do for making our 
final transition to C++11 a bit easier. I do however see that my approach 
caused code duplication. Feeling unsure which route to take, I left it this 
way. Let me know if that is a problem as I would be happy to adapt to whatever 
is recommended by the committers.


- TILL


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


On Feb. 22, 2014, 1:05 a.m., TILL TOENSHOFF wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18311/
> ---
> 
> (Updated Feb. 22, 2014, 1:05 a.m.)
> 
> 
> Review request for mesos, Adam B, Benjamin Hindman, Ben Mahler, Niklas 
> Nielsen, and Vinod Kone.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Currently the Process::await implementation on list, by the nature of 
> std::list, expects equally typed futures. This new override implements await 
> for a tuple of futures, hence allows awaiting differently typed futures in a 
> single call.
> 
> There also is a new override that allows await on a single Future, a 
> convenience approach for allowing a Process based await on a single Future 
> without forcing the user to render a list or tuple out of that. 
> 
> A C++11 and a boost-based implementation have been added.
> 
> This patch also includes tests on those new overrides.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/include/process/c++11/collect.hpp PRE-CREATION 
>   3rdparty/libprocess/include/process/collect.hpp 2a73bc9 
>   3rdparty/libprocess/src/tests/process_tests.cpp e899aed 
> 
> Diff: https://reviews.apache.org/r/18311/diff/
> 
> 
> Testing
> ---
> 
> make check (clang c++11, gcc)
> 
> 
> Thanks,
> 
> TILL TOENSHOFF
> 
>

Re: Review Request 18311: Adds await on a tuple of futures.

[TILL TOENSHOFF]

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

(Updated Feb. 22, 2014, 1:05 a.m.)


Review request for mesos, Adam B, Benjamin Hindman, Ben Mahler, Niklas Nielsen, 
and Vinod Kone.


Changes
---

Now based on namespace pull-in of tuples into stout (RR 18360).


Repository: mesos-git


Description
---

Currently the Process::await implementation on list, by the nature of 
std::list, expects equally typed futures. This new override implements await 
for a tuple of futures, hence allows awaiting differently typed futures in a 
single call.

There also is a new override that allows await on a single Future, a 
convenience approach for allowing a Process based await on a single Future 
without forcing the user to render a list or tuple out of that. 

A C++11 and a boost-based implementation have been added.

This patch also includes tests on those new overrides.


Diffs (updated)
-

  3rdparty/libprocess/include/process/c++11/collect.hpp PRE-CREATION 
  3rdparty/libprocess/include/process/collect.hpp 2a73bc9 
  3rdparty/libprocess/src/tests/process_tests.cpp e899aed 

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


Testing
---

make check (clang c++11, gcc)


Thanks,

TILL TOENSHOFF

Re: Review Request 18386: Option reference cleanup in mesos

[Dominic Hamon]

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

(Updated Feb. 21, 2014, 4:51 p.m.)


Review request for mesos and Ben Mahler.


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


Repository: mesos-git


Description
---

See summary


Diffs (updated)
-

  src/linux/fs.hpp 1d86dd0d24c3daae957b5eec387638d1e8e6d7db 
  src/linux/fs.cpp e5f4f9a16becd4e5960d0cbb7f988736188b2426 
  src/log/catchup.cpp bcad2782d85aeb473f75e56b2e2f2874b32302e8 
  src/log/log.cpp 62dc9286285d5981aa5fc63e125d3c3f51d4f457 
  src/sched/sched.cpp dcb3158d2acd93a107fda51b19e92899a092e628 

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


Testing
---

make check


Thanks,

Dominic Hamon

Re: Review Request 18249: Removed 'using namespace process' from header files.

[Ben Mahler]

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


This patch needs a rebase to apply correctly:

error: patch failed: src/master/master.hpp:489
error: src/master/master.hpp: patch does not apply
error: src/slave/cgroups_isolator.hpp: does not exist in index
error: src/slave/cgroups_isolator.cpp: does not exist in index
error: src/slave/process_isolator.hpp: does not exist in index
error: patch failed: src/slave/slave.hpp:260
error: src/slave/slave.hpp: patch does not apply
error: patch failed: src/slave/slave.cpp:60
error: src/slave/slave.cpp: patch does not apply
Failed to apply patch

- Ben Mahler


On Feb. 19, 2014, 6:29 p.m., Dominic Hamon wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18249/
> ---
> 
> (Updated Feb. 19, 2014, 6:29 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Ben Mahler, and Vinod Kone.
> 
> 
> Bugs: MESOS-1015
> https://issues.apache.org/jira/browse/MESOS-1015
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> See summary
> 
> 
> Diffs
> -
> 
>   src/master/hierarchical_allocator_process.hpp 
> 96b6ad569ea3758e4d078c6b2d60da4ea4fe8693 
>   src/master/http.cpp 966eed6d8340038265ef799f1b6149502ccc606e 
>   src/master/master.hpp 737bd8b5a1cd88a98a7f094795c50547079921ba 
>   src/master/master.cpp a4e1b1f7327f01eb16f14c3fa08fc7a62048d36c 
>   src/slave/cgroups_isolator.hpp 1a66dc630f0857db48b7cfb316fbbb15518fcec2 
>   src/slave/cgroups_isolator.cpp ef7dd682e5462d0158d6ea6654246d77000e9778 
>   src/slave/http.cpp c4f598faf6807214608cc89a6d9cf665133f95f3 
>   src/slave/process_isolator.hpp bc52f33d8e83fe026be712c8b15e689eb23dd65c 
>   src/slave/slave.hpp 2ddadb411f8b2f91a4a5038664f424d4eadfbb87 
>   src/slave/slave.cpp 213df86084e51ab8407c6f2c2bd24ba718560faa 
>   src/slave/status_update_manager.hpp 
> 06ea4659cdd24cb1b82f389f404566ba14a663fb 
>   src/slave/status_update_manager.cpp 
> 03f5eafefd6ed748bfd4511d654c23c7b460db66 
> 
> Diff: https://reviews.apache.org/r/18249/diff/
> 
> 
> Testing
> ---
> 
> no functional change expected.
> 
> built. ran make check.
> 
> 
> Thanks,
> 
> Dominic Hamon
> 
>

Re: Review Request 18321: Replaced static non-PODs with pointers and removed dead code.

[Ben Mahler]

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

Ship it!


Ship It!

- Ben Mahler


On Feb. 22, 2014, 12:21 a.m., Dominic Hamon wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18321/
> ---
> 
> (Updated Feb. 22, 2014, 12:21 a.m.)
> 
> 
> Review request for mesos, Ben Mahler and Vinod Kone.
> 
> 
> Bugs: MESOS-1023
> https://issues.apache.org/jira/browse/MESOS-1023
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> See summary
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/include/process/clock.hpp 
> 82ae3c6f4928388d041803068a2a4362ddc3bcd5 
>   3rdparty/libprocess/include/process/logging.hpp 
> f4fb6196c875d2eb6dab9f4514b98936517ff176 
>   3rdparty/libprocess/include/process/time.hpp 
> 26cec3dadca8aa5b33964c5072be4671aa42a259 
>   3rdparty/libprocess/include/process/timeseries.hpp 
> b368b9bb9cd63fb331b2c137dcde759d0ee59ee6 
>   3rdparty/libprocess/src/process.cpp 
> 69898b7fff36fa5de048782ccbba63ce4a35f7c8 
>   3rdparty/libprocess/src/synchronized.cpp 
> 79b0849accd41d291fd083601cea7d4fe92782cf 
>   3rdparty/libprocess/src/timer.hpp 443b5a0f56f32193f90c11b7f0da76eabd9ecfde 
>   3rdparty/libprocess/src/timer.cpp aa1ee1bad51dbff7d81e49f242156e8ab25e6944 
> 
> Diff: https://reviews.apache.org/r/18321/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dominic Hamon
> 
>

Re: Review Request 18321: Replaced static non-PODs with pointers and removed dead code.

[Dominic Hamon]

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

(Updated Feb. 21, 2014, 4:21 p.m.)


Review request for mesos, Ben Mahler and Vinod Kone.


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


Repository: mesos-git


Description
---

See summary


Diffs (updated)
-

  3rdparty/libprocess/include/process/clock.hpp 
82ae3c6f4928388d041803068a2a4362ddc3bcd5 
  3rdparty/libprocess/include/process/logging.hpp 
f4fb6196c875d2eb6dab9f4514b98936517ff176 
  3rdparty/libprocess/include/process/time.hpp 
26cec3dadca8aa5b33964c5072be4671aa42a259 
  3rdparty/libprocess/include/process/timeseries.hpp 
b368b9bb9cd63fb331b2c137dcde759d0ee59ee6 
  3rdparty/libprocess/src/process.cpp 69898b7fff36fa5de048782ccbba63ce4a35f7c8 
  3rdparty/libprocess/src/synchronized.cpp 
79b0849accd41d291fd083601cea7d4fe92782cf 
  3rdparty/libprocess/src/timer.hpp 443b5a0f56f32193f90c11b7f0da76eabd9ecfde 
  3rdparty/libprocess/src/timer.cpp aa1ee1bad51dbff7d81e49f242156e8ab25e6944 

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


Testing
---


Thanks,

Dominic Hamon

Re: Review Request 18383: Changed Option::get to return const reference to reduce copying.

[Dominic Hamon]

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

(Updated Feb. 21, 2014, 4:17 p.m.)


Review request for mesos and Ben Mahler.


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


Repository: mesos-git


Description
---

See summary


Diffs (updated)
-

  3rdparty/libprocess/3rdparty/stout/include/stout/option.hpp 
3305d1363adfffc5e54ff1617e6e7c3c29f7e200 
  3rdparty/libprocess/3rdparty/stout/include/stout/try.hpp 
d99b75aeae10319b574c67beeb6023358cac7aec 

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


Testing
---

make check


Thanks,

Dominic Hamon

Re: Review Request 18321: Replaced static non-PODs with pointers and removed dead code.

[Dominic Hamon]

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

(Updated Feb. 21, 2014, 4:04 p.m.)


Review request for mesos, Ben Mahler and Vinod Kone.


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


Repository: mesos-git


Description
---

See summary


Diffs (updated)
-

  3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp 
778398af0e166709a777d770b7fddda309a60add 
  3rdparty/libprocess/3rdparty/stout/tests/json_tests.cpp 
267b5f95958e51a003657cec6689a81f2b7763a7 
  3rdparty/libprocess/include/process/clock.hpp 
82ae3c6f4928388d041803068a2a4362ddc3bcd5 
  3rdparty/libprocess/include/process/logging.hpp 
f4fb6196c875d2eb6dab9f4514b98936517ff176 
  3rdparty/libprocess/include/process/time.hpp 
26cec3dadca8aa5b33964c5072be4671aa42a259 
  3rdparty/libprocess/include/process/timeseries.hpp 
b368b9bb9cd63fb331b2c137dcde759d0ee59ee6 
  3rdparty/libprocess/src/process.cpp 69898b7fff36fa5de048782ccbba63ce4a35f7c8 
  3rdparty/libprocess/src/synchronized.cpp 
79b0849accd41d291fd083601cea7d4fe92782cf 
  3rdparty/libprocess/src/timer.hpp 443b5a0f56f32193f90c11b7f0da76eabd9ecfde 
  3rdparty/libprocess/src/timer.cpp aa1ee1bad51dbff7d81e49f242156e8ab25e6944 
  docs/mesos-presentations.md 587c5af179c45dcb6184cb128b1dc6aa1c9569df 
  src/Makefile.am f1ceab30902103e0ec8faa742bf5fa9346952394 
  src/local/local.cpp e31c19c1bd0bc527275b818a8ce2bc1d54d8cb89 
  src/master/main.cpp 723d534726175287b9ca3bffed894f77433183f4 
  src/master/master.hpp 768dc3d165510d9e65e4b44075256b2805fde18c 
  src/master/master.cpp de40884f873656cf91566ef49736cb8dda1300d8 
  src/master/registrar.hpp 20734afc69055197e9ab90d42253c56e4af4b97c 
  src/master/registrar.cpp 470a40511cf1ac9a379d76a76453df89101d7489 
  src/master/registry.proto b58cae532764036748eaabd95f07188a1397 
  src/master/repairer.hpp d5c6b8494993f72012d2aa562e708f78b2fad678 
  src/master/repairer.cpp 151b4ed7ac0b8dacd175b97d372c1f867cd280f6 
  src/tests/cluster.hpp d1bf680ed3f6a0fb16af85a21409d653d44522ca 
  src/tests/registrar_tests.cpp 3bf42bd77a10470a2afc6fd8e1da30d6134e792c 

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


Testing
---


Thanks,

Dominic Hamon

Re: Review Request 18321: Replaced static non-PODs with pointers and removed dead code.

[Dominic Hamon]

> On Feb. 20, 2014, 2:27 p.m., Ben Mahler wrote:
> > 3rdparty/libprocess/include/process/help.hpp, lines 37-38
> > 
> >
> > Rather than return a pointer, seems like the responsibility of proper 
> > static storage should lie in the caller, no? I think HELP should be 
> > agnostic to how it is being called.
> 
> Dominic Hamon wrote:
> true, but then all the callsites will have to remember to write:
> 
> const std::string* THIS_HELP = new std::string(HELP());
> 
> given 'HELP' looks like a macro that just does the write thing, it can 
> help out by returning a heap-allocated string pointer.
> 
> Ben Mahler wrote:
> But I'm wondering whether we can change the current style of HELP usage 
> to avoid this.
> 
> We only need to compute the HELP string once during initialize(), for 
> route()ing purposes. So, for example, a static function might be a good 
> alternative for callers:
> 
> System
> {
>   initialize()
>   {
> route("/stats.json", STATS_HELP(), &System::stats);
>   }
> 
>   // This could live only in the .cpp file outside the System class if we 
> implement initialize() in the .cpp.
>   static std::string STATS_HELP()
> }
> 
> What do you think?

That seems reasonable. It puts the onus on the callsite to use HELP responsibly 
and doesn't require any changes to process.


- Dominic


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


On Feb. 20, 2014, 3:19 p.m., Dominic Hamon wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18321/
> ---
> 
> (Updated Feb. 20, 2014, 3:19 p.m.)
> 
> 
> Review request for mesos, Ben Mahler and Vinod Kone.
> 
> 
> Bugs: MESOS-1023
> https://issues.apache.org/jira/browse/MESOS-1023
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> See summary
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/include/process/clock.hpp 
> 82ae3c6f4928388d041803068a2a4362ddc3bcd5 
>   3rdparty/libprocess/include/process/help.hpp 
> 8d50419d9e794c64aecc5c8a906d3b1f6a288fac 
>   3rdparty/libprocess/include/process/time.hpp 
> 26cec3dadca8aa5b33964c5072be4671aa42a259 
>   3rdparty/libprocess/include/process/timeseries.hpp 
> b368b9bb9cd63fb331b2c137dcde759d0ee59ee6 
>   3rdparty/libprocess/src/process.cpp 
> 69898b7fff36fa5de048782ccbba63ce4a35f7c8 
>   3rdparty/libprocess/src/synchronized.cpp 
> 79b0849accd41d291fd083601cea7d4fe92782cf 
>   3rdparty/libprocess/src/timer.hpp 443b5a0f56f32193f90c11b7f0da76eabd9ecfde 
>   3rdparty/libprocess/src/timer.cpp aa1ee1bad51dbff7d81e49f242156e8ab25e6944 
> 
> Diff: https://reviews.apache.org/r/18321/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dominic Hamon
> 
>

[jira] [Commented] (MESOS-1008) Reduce copying in stout / libprocess primitives {Try, Option, Result, Future}.

[Dominic Hamon (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13909002#comment-13909002
 ] 

Dominic Hamon commented on MESOS-1008:
--

Changes to Option:
https://reviews.apache.org/r/18383/
https://reviews.apache.org/r/18384/
https://reviews.apache.org/r/18386/

> Reduce copying in stout / libprocess primitives {Try, Option, Result, Future}.
> --
>
> Key: MESOS-1008
> URL: https://issues.apache.org/jira/browse/MESOS-1008
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Benjamin Mahler
>Assignee: Benjamin Mahler
>
> The following will discuss {{Try}}, but the same applies to {{Option}} and 
> {{Result}}.
> Currently retrieving the value from a {{Try}} requires a copy:
> {code}
>   T get() const { ... return *t; }
> {code}
> Instead, we can return a const&:
> {code}
>   const T& get() const { ... return *t; }
> {code}
> For existing callers, this should be fairly seamless:
> {code}
>   const T& t = try.get(); // No change needed.
>   T t = try.get(); // No change needed, T is already required to be copyable.
>   try.get().mutator(); // Will no longer compile, but we should not allow 
> this anyway!
> {code}
> {code}
>   const T& t = try.get();
>   try = T(); // t is now garbage!
>   t.foo(); // No longer works.
> {code}
> The last case is the most concerning as this mistake cannot be caught at 
> compile-time. We could remove the assignment operators, but this seems overly 
> restrictive. We could also guard (via {{CHECK}}) the assignment operator 
> after a {{get()}} operation, but of course, we're also preventing valid 
> {{Try}} usage if we go this route. The best path may simply be to leave the 
> assignment operators as is (many callers already make copies).
> We can also add C++11 support for move to pilfer the {{Try}}, to avoid copies 
> in the caller entirely:
> {code}
>   T&& move() const { ... } // After a move(), we must guard Try operations.
> {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Review Request 18383: Changed Option::get to return const reference to reduce copying.

[Dominic Hamon]

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

Review request for mesos and Ben Mahler.


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


Repository: mesos-git


Description
---

See summary


Diffs
-

  3rdparty/libprocess/3rdparty/stout/include/stout/option.hpp 
3305d1363adfffc5e54ff1617e6e7c3c29f7e200 
  3rdparty/libprocess/3rdparty/stout/include/stout/try.hpp 
d99b75aeae10319b574c67beeb6023358cac7aec 

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


Testing
---

make check


Thanks,

Dominic Hamon

Review Request 18384: Option reference cleanup in process

[Dominic Hamon]

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

Review request for mesos and Ben Mahler.


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


Repository: mesos-git


Description
---

See summary


Diffs
-

  3rdparty/libprocess/include/process/future.hpp 
e45f4f79faeefbffc28d855d2f74e8df69099f18 

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


Testing
---

make check


Thanks,

Dominic Hamon

Review Request 18386: Option reference cleanup in mesos

[Dominic Hamon]

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

Review request for mesos and Ben Mahler.


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


Repository: mesos-git


Description
---

See summary


Diffs
-

  src/sched/sched.cpp dcb3158d2acd93a107fda51b19e92899a092e628 

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


Testing
---

make check


Thanks,

Dominic Hamon

Re: Review Request 18321: Replaced static non-PODs with pointers and removed dead code.

[Ben Mahler]

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



3rdparty/libprocess/src/process.cpp


Full sentence please :)


- Ben Mahler


On Feb. 20, 2014, 11:19 p.m., Dominic Hamon wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18321/
> ---
> 
> (Updated Feb. 20, 2014, 11:19 p.m.)
> 
> 
> Review request for mesos, Ben Mahler and Vinod Kone.
> 
> 
> Bugs: MESOS-1023
> https://issues.apache.org/jira/browse/MESOS-1023
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> See summary
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/include/process/clock.hpp 
> 82ae3c6f4928388d041803068a2a4362ddc3bcd5 
>   3rdparty/libprocess/include/process/help.hpp 
> 8d50419d9e794c64aecc5c8a906d3b1f6a288fac 
>   3rdparty/libprocess/include/process/time.hpp 
> 26cec3dadca8aa5b33964c5072be4671aa42a259 
>   3rdparty/libprocess/include/process/timeseries.hpp 
> b368b9bb9cd63fb331b2c137dcde759d0ee59ee6 
>   3rdparty/libprocess/src/process.cpp 
> 69898b7fff36fa5de048782ccbba63ce4a35f7c8 
>   3rdparty/libprocess/src/synchronized.cpp 
> 79b0849accd41d291fd083601cea7d4fe92782cf 
>   3rdparty/libprocess/src/timer.hpp 443b5a0f56f32193f90c11b7f0da76eabd9ecfde 
>   3rdparty/libprocess/src/timer.cpp aa1ee1bad51dbff7d81e49f242156e8ab25e6944 
> 
> Diff: https://reviews.apache.org/r/18321/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dominic Hamon
> 
>

Re: Review Request 18321: Replaced static non-PODs with pointers and removed dead code.

[Ben Mahler]

> On Feb. 20, 2014, 10:27 p.m., Ben Mahler wrote:
> > 3rdparty/libprocess/include/process/help.hpp, lines 37-38
> > 
> >
> > Rather than return a pointer, seems like the responsibility of proper 
> > static storage should lie in the caller, no? I think HELP should be 
> > agnostic to how it is being called.
> 
> Dominic Hamon wrote:
> true, but then all the callsites will have to remember to write:
> 
> const std::string* THIS_HELP = new std::string(HELP());
> 
> given 'HELP' looks like a macro that just does the write thing, it can 
> help out by returning a heap-allocated string pointer.

But I'm wondering whether we can change the current style of HELP usage to 
avoid this.

We only need to compute the HELP string once during initialize(), for 
route()ing purposes. So, for example, a static function might be a good 
alternative for callers:

System
{
  initialize()
  {
route("/stats.json", STATS_HELP(), &System::stats);
  }

  // This could live only in the .cpp file outside the System class if we 
implement initialize() in the .cpp.
  static std::string STATS_HELP()
}

What do you think?


- Ben


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


On Feb. 20, 2014, 11:19 p.m., Dominic Hamon wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18321/
> ---
> 
> (Updated Feb. 20, 2014, 11:19 p.m.)
> 
> 
> Review request for mesos, Ben Mahler and Vinod Kone.
> 
> 
> Bugs: MESOS-1023
> https://issues.apache.org/jira/browse/MESOS-1023
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> See summary
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/include/process/clock.hpp 
> 82ae3c6f4928388d041803068a2a4362ddc3bcd5 
>   3rdparty/libprocess/include/process/help.hpp 
> 8d50419d9e794c64aecc5c8a906d3b1f6a288fac 
>   3rdparty/libprocess/include/process/time.hpp 
> 26cec3dadca8aa5b33964c5072be4671aa42a259 
>   3rdparty/libprocess/include/process/timeseries.hpp 
> b368b9bb9cd63fb331b2c137dcde759d0ee59ee6 
>   3rdparty/libprocess/src/process.cpp 
> 69898b7fff36fa5de048782ccbba63ce4a35f7c8 
>   3rdparty/libprocess/src/synchronized.cpp 
> 79b0849accd41d291fd083601cea7d4fe92782cf 
>   3rdparty/libprocess/src/timer.hpp 443b5a0f56f32193f90c11b7f0da76eabd9ecfde 
>   3rdparty/libprocess/src/timer.cpp aa1ee1bad51dbff7d81e49f242156e8ab25e6944 
> 
> Diff: https://reviews.apache.org/r/18321/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dominic Hamon
> 
>

Re: Review Request 18360: Include std::tuple or boost::tuples::tuple within a tuples namespace of stout.

[Adam B]

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

Ship it!


Ship It!

- Adam B


On Feb. 21, 2014, 3:28 p.m., TILL TOENSHOFF wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18360/
> ---
> 
> (Updated Feb. 21, 2014, 3:28 p.m.)
> 
> 
> Review request for mesos, Adam B, Benjamin Hindman, Ben Mahler, Niklas 
> Nielsen, and Vinod Kone.
> 
> 
> Bugs: MESOS-1026
> https://issues.apache.org/jira/browse/MESOS-1026
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Namespace pull-in of std::tuple or boost::tuples::tuple, depending on the 
> availability of C+11. The results are part of a tuples namespace of stout.
> 
> Example usage including fully qualified namespaces:
> 
> #include 
> tuples::tuple tuple = tuples::make_tuple(42, true);
> int foo = tuples::get<0>(tuple);
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/stout/Makefile.am 5d5a760 
>   3rdparty/libprocess/3rdparty/stout/include/stout/tuple.hpp PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/18360/diff/
> 
> 
> Testing
> ---
> 
> make check (clang c++11, gcc), functional testing
> 
> 
> Thanks,
> 
> TILL TOENSHOFF
> 
>

Re: Review Request 18360: Include std::tuple or boost::tuples::tuple within a tuples namespace of stout.

[TILL TOENSHOFF]

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

(Updated Feb. 21, 2014, 11:28 p.m.)


Review request for mesos, Adam B, Benjamin Hindman, Ben Mahler, Niklas Nielsen, 
and Vinod Kone.


Changes
---

Moved to stout.


Summary (updated)
-

Include std::tuple or boost::tuples::tuple within a tuples namespace of stout.


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


Repository: mesos-git


Description (updated)
---

Namespace pull-in of std::tuple or boost::tuples::tuple, depending on the 
availability of C+11. The results are part of a tuples namespace of stout.

Example usage including fully qualified namespaces:

#include 
tuples::tuple tuple = tuples::make_tuple(42, true);
int foo = tuples::get<0>(tuple);


Diffs (updated)
-

  3rdparty/libprocess/3rdparty/stout/Makefile.am 5d5a760 
  3rdparty/libprocess/3rdparty/stout/include/stout/tuple.hpp PRE-CREATION 

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


Testing
---

make check (clang c++11, gcc), functional testing


Thanks,

TILL TOENSHOFF

[jira] [Commented] (MESOS-804) Add authentication support for slaves

[Adam B (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908971#comment-13908971
 ] 

Adam B commented on MESOS-804:
--

Up for review at: https://reviews.apache.org/r/18381/

> Add authentication support for slaves
> -
>
> Key: MESOS-804
> URL: https://issues.apache.org/jira/browse/MESOS-804
> Project: Mesos
>  Issue Type: Story
>Reporter: Vinod Kone
>Assignee: Vinod Kone
>




--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Review Request 18381: Added authentication support for slaves.

[Adam B]

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

Review request for mesos, Benjamin Hindman, Niklas Nielsen, and Vinod Kone.


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


Repository: mesos-git


Description
---

Added authentication support for slaves.
Fixes MESOS-804.

Open Issues:
- Should AuthenticateMessage be replaced with AuthenticateFrameworkMessage, or 
specify an Authenticatee type as coded here?
- removeSlave vs. deactivate(Slave): Some uses of removeSlave might benefit 
from just deactivating if checkpointing is enabled.
- We currently deactivate a registered slave/framework when a new authenticate 
message comes in, even if the new authentication message is a failure/fake. 
Will file a new JIRA for this security hole.
- When multiple entries for the same principal exist in the credentials file, 
only the last entry is used. Acceptable behavior, but shouldn't this be 
documented?


Diffs
-

  src/master/flags.hpp 159b2de 
  src/master/master.hpp 768dc3d 
  src/master/master.cpp de40884 
  src/messages/messages.proto 922a8c4 
  src/sasl/authenticatee.hpp 42a4eba 
  src/sched/sched.cpp dcb3158 
  src/slave/flags.hpp e4d98a5 
  src/slave/main.cpp 8aba4ed 
  src/slave/slave.hpp d82d4e9 
  src/slave/slave.cpp 7ad8232 
  src/tests/authentication_tests.cpp 127c5e6 
  src/tests/mesos.cpp 96adeac 
  src/tests/sasl_tests.cpp 945426d 

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


Testing
---

make check; manually tested flatfile slave authentication success/failure.
Unit test pending.


Thanks,

Adam B

[jira] [Updated] (MESOS-969) resource allocation (memory) beyond availability

[Ashutosh Jain (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ashutosh Jain updated MESOS-969:


Affects Version/s: 0.18.0

> resource allocation (memory) beyond availability
> 
>
> Key: MESOS-969
> URL: https://issues.apache.org/jira/browse/MESOS-969
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.14.2, 0.18.0
>Reporter: Ashutosh Jain
>Priority: Minor
>
> I am running my mesos 0.14.2 instance in virtual-box. I had allocated 1466 MB 
> of memory to it.
>  
> 1. I created the server at 127.0.1.1:5050.
> ./mesos-master.sh 
> 2. then I added the system itself as slave and allocated 2000 MB of memory 
> using 
> ./mesos-slave.sh --master=127.0.1.1:5050 --resources=mem:2000
> and the resources were happily allocated to it.
> (allocated memory was being shown in the GUI at 127.0.1.1:5050 in the browser)
> I even tried with 2 of memory and still the same results .
> basically it not being checked whether the resources are even available or 
> not .



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (MESOS-1026) Pull std::tuple / boost::tuples::tuple into tuples namespace of stout

[Till Toenshoff (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Till Toenshoff updated MESOS-1026:
--

Description: 
For allowing a smooth transition into the C++11 world, I would like to propose 
doing a namespace pull-in of std::tuple or boost::tuples::tuple, depending on 
the availability of C++11. The results should be part of the tuples namespace 
of stout.

Review-request is upcoming but I wanted to make sure that this improvement 
could be discussed outside the review-request.


  was:
For allowing a smooth transition into the C++11 world, I would like to propose 
doing a namespace pull-in of std::tuple or boost::tuples::tuple, depending on 
the availability of C++11. The results should be part of the process::tuples 
namespace.

Review-request is upcoming but I wanted to make sure that this improvement 
could be discussed outside the review-request.



> Pull std::tuple / boost::tuples::tuple into tuples namespace of stout
> -
>
> Key: MESOS-1026
> URL: https://issues.apache.org/jira/browse/MESOS-1026
> Project: Mesos
>  Issue Type: Improvement
>  Components: libprocess
>Affects Versions: 0.19.0
>Reporter: Till Toenshoff
>Priority: Minor
>  Labels: boost, c++11, libprocess, tuple
>
> For allowing a smooth transition into the C++11 world, I would like to 
> propose doing a namespace pull-in of std::tuple or boost::tuples::tuple, 
> depending on the availability of C++11. The results should be part of the 
> tuples namespace of stout.
> Review-request is upcoming but I wanted to make sure that this improvement 
> could be discussed outside the review-request.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (MESOS-1026) Pull std::tuple / boost::tuples::tuple into tuples namespace of stout

[Till Toenshoff (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Till Toenshoff updated MESOS-1026:
--

Summary: Pull std::tuple / boost::tuples::tuple into tuples namespace of 
stout  (was: Pull std::tuple / boost::tuples::tuple into Process::tuples 
namespace)

> Pull std::tuple / boost::tuples::tuple into tuples namespace of stout
> -
>
> Key: MESOS-1026
> URL: https://issues.apache.org/jira/browse/MESOS-1026
> Project: Mesos
>  Issue Type: Improvement
>  Components: libprocess
>Affects Versions: 0.19.0
>Reporter: Till Toenshoff
>Priority: Minor
>  Labels: boost, c++11, libprocess, tuple
>
> For allowing a smooth transition into the C++11 world, I would like to 
> propose doing a namespace pull-in of std::tuple or boost::tuples::tuple, 
> depending on the availability of C++11. The results should be part of the 
> process::tuples namespace.
> Review-request is upcoming but I wanted to make sure that this improvement 
> could be discussed outside the review-request.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (MESOS-1026) Pull std::tuple / boost::tuples::tuple into Process::tuples namespace

[Till Toenshoff (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908929#comment-13908929
 ] 

Till Toenshoff commented on MESOS-1026:
---

I never realized that this was the case. Thanks for pointing it out Ben. I 
totally agree that stout was the right place for this, it was just the 
dependency that prevented me from doing so.

Will update my RR accordingly.


> Pull std::tuple / boost::tuples::tuple into Process::tuples namespace
> -
>
> Key: MESOS-1026
> URL: https://issues.apache.org/jira/browse/MESOS-1026
> Project: Mesos
>  Issue Type: Improvement
>  Components: libprocess
>Affects Versions: 0.19.0
>Reporter: Till Toenshoff
>Priority: Minor
>  Labels: boost, c++11, libprocess, tuple
>
> For allowing a smooth transition into the C++11 world, I would like to 
> propose doing a namespace pull-in of std::tuple or boost::tuples::tuple, 
> depending on the availability of C++11. The results should be part of the 
> process::tuples namespace.
> Review-request is upcoming but I wanted to make sure that this improvement 
> could be discussed outside the review-request.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (MESOS-764) Implement Master persistence using the Registrar.

[Benjamin Mahler (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908890#comment-13908890
 ] 

Benjamin Mahler commented on MESOS-764:
---

Related patches so far:

(1) Initial Registrar: https://reviews.apache.org/r/14383/ (committed)
(2) Injection: https://reviews.apache.org/r/14384/ (committed)
(3) Cleanup from (1): https://reviews.apache.org/r/15099/ (committed)
(4) Registry Format: https://reviews.apache.org/r/18158/
(5) More cleanup: https://reviews.apache.org/r/18341/

I'll also be resurrecting my old patches for recovery, master integration, 
upgrading, performance testing.

> Implement Master persistence using the Registrar.
> -
>
> Key: MESOS-764
> URL: https://issues.apache.org/jira/browse/MESOS-764
> Project: Mesos
>  Issue Type: Improvement
>  Components: master
>Reporter: Benjamin Mahler
>Assignee: Benjamin Mahler
>  Labels: twitter
> Fix For: 0.19.0
>
>
> Design document:
> https://cwiki.apache.org/confluence/display/MESOS/Registrar+Design+Document
> Using the registrar as a means for persistent, highly available storage of 
> the slave information will allow us to recover slave information when a 
> master is elected as a leader.
> Having persistent slave information will allow the master to answer 
> reconciliation requests from frameworks in a correct and reliable manner. 
> There are currently cases where we cannot answer reconciliation requests in 
> order to avoid providing an incorrect answer (hints in MESOS-295).
> It will also ensure that when we inform the world that a slave is removed, we 
> can enforce that as truth even with the presence of dropped messages and 
> master failovers.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: Review Request 18333: Updated Makefile.am for the new interval set tests.

[Benjamin Mahler]

No need to publish if the diff is empty:

https://reviews.apache.org/r/18333/diff/1-2/
https://reviews.apache.org/r/18333/diff/2-3/

Saves having to read email :)

-- Forwarded message --
From: Jie Yu 
Date: Fri, Feb 21, 2014 at 11:24 AM
Subject: Re: Review Request 18333: Updated Makefile.am for the new interval
set tests.
To: Ben Mahler 
Cc: Jie Yu , mesos 



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

(Updated Feb. 21, 2014, 7:24 p.m.)


Review request for mesos and Ben Mahler.


Changes
---

Rebased.


Repository: mesos-git


Description
---

See summary. Separated patch for libprocess.


Diffs (updated)
-

  3rdparty/libprocess/3rdparty/Makefile.am 51b118c

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


Testing
---

make check


Thanks,

Jie Yu

[jira] [Updated] (MESOS-1008) Reduce copying in stout / libprocess primitives {Try, Option, Result, Future}.

[Benjamin Mahler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benjamin Mahler updated MESOS-1008:
---

Description: 
The following will discuss {{Try}}, but the same applies to {{Option}} and 
{{Result}}.

Currently retrieving the value from a {{Try}} requires a copy:

{code}
  T get() const { ... return *t; }
{code}

Instead, we can return a const&:

{code}
  const T& get() const { ... return *t; }
{code}

For existing callers, this should be fairly seamless:

{code}
  const T& t = try.get(); // No change needed.
  T t = try.get(); // No change needed, T is already required to be copyable.
  try.get().mutator(); // Will no longer compile, but we should not allow this 
anyway!
{code}

{code}
  const T& t = try.get();
  try = T(); // t is now garbage!
  t.foo(); // No longer works.
{code}

The last case is the most concerning as this mistake cannot be caught at 
compile-time. We could remove the assignment operators, but this seems overly 
restrictive. We could also guard (via {{CHECK}}) the assignment operator after 
a {{get()}} operation, but of course, we're also preventing valid {{Try}} usage 
if we go this route. The best path may simply be to leave the assignment 
operators as is (many callers already make copies).

We can also add C++11 support for move to pilfer the {{Try}}, to avoid copies 
in the caller entirely:

{code}
  T&& move() const { ... } // After a move(), we must guard Try operations.
{code}

  was:
The following will discuss Try, but the same applies to Option and Result.

Currently retrieving the value from a Try requires a copy:

  T get() const { ... return *t; }

Instead, we can return a const&:

  const T& get() const { ... return *t; }

For existing callers, this should be fairly seamless:
  const T& t = try.get(); // No change needed.
  T t = try.get(); // No change needed, T is already required to be copyable.
  try.get().mutator(); // Will no longer compile, but we should not allow this 
anyway!

  const T& t = try.get();
  try = T(); // t is now garbage!
  t.foo(); // No longer works.

The last case is the most concerning as this mistake cannot be caught at 
compile-time. We could remove the assignment operators, but this seems overly 
restrictive. We could also guard (via CHECK) the assignment operator after a 
get() operation, but of course, we're also preventing valid Try usage if we go 
this route. The best path may simply be to leave the assignment operators as is 
(many callers already make copies).

We can also add C++11 support for move to pilfer the Try, to avoid copies in 
the caller entirely:

  T&& move() const { ... } // After a move(), we must guard Try operations.


> Reduce copying in stout / libprocess primitives {Try, Option, Result, Future}.
> --
>
> Key: MESOS-1008
> URL: https://issues.apache.org/jira/browse/MESOS-1008
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Benjamin Mahler
>Assignee: Benjamin Mahler
>
> The following will discuss {{Try}}, but the same applies to {{Option}} and 
> {{Result}}.
> Currently retrieving the value from a {{Try}} requires a copy:
> {code}
>   T get() const { ... return *t; }
> {code}
> Instead, we can return a const&:
> {code}
>   const T& get() const { ... return *t; }
> {code}
> For existing callers, this should be fairly seamless:
> {code}
>   const T& t = try.get(); // No change needed.
>   T t = try.get(); // No change needed, T is already required to be copyable.
>   try.get().mutator(); // Will no longer compile, but we should not allow 
> this anyway!
> {code}
> {code}
>   const T& t = try.get();
>   try = T(); // t is now garbage!
>   t.foo(); // No longer works.
> {code}
> The last case is the most concerning as this mistake cannot be caught at 
> compile-time. We could remove the assignment operators, but this seems overly 
> restrictive. We could also guard (via {{CHECK}}) the assignment operator 
> after a {{get()}} operation, but of course, we're also preventing valid 
> {{Try}} usage if we go this route. The best path may simply be to leave the 
> assignment operators as is (many callers already make copies).
> We can also add C++11 support for move to pilfer the {{Try}}, to avoid copies 
> in the caller entirely:
> {code}
>   T&& move() const { ... } // After a move(), we must guard Try operations.
> {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: Review Request 18339: Added TaskID validation check.

[Ben Mahler]

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


Have you looked at the source code of the open source Mesos frameworks to make 
sure we won't be breaking them? I seem to recall Chronos or Marathon using ':'.

- Ben Mahler


On Feb. 21, 2014, 6:21 p.m., Dominic Hamon wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18339/
> ---
> 
> (Updated Feb. 21, 2014, 6:21 p.m.)
> 
> 
> Review request for mesos, Ben Mahler and Vinod Kone.
> 
> 
> Bugs: MESOS-361
> https://issues.apache.org/jira/browse/MESOS-361
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> See summary.
> 
> It would be good to have specific unit tests for these validators. I could 
> pull out the validation to another file and add unit tests on them.
> 
> Final validation for TaskID is awaiting consensus (or as close as we can get) 
> on bug/mailing list. I do prefer to be conservative but I don't want to break 
> users.
> 
> 
> Diffs
> -
> 
>   src/master/master.hpp 9d1b56c6b02eb21130f165848297ae0695ac2af7 
>   src/master/master.cpp cb46869cd298f3a4fcbe8e4e3fea4bb7c741a0e0 
> 
> Diff: https://reviews.apache.org/r/18339/diff/
> 
> 
> Testing
> ---
> 
> built. ran make check. ran local master/slave/python framework.
> 
> 
> Thanks,
> 
> Dominic Hamon
> 
>

Re: Review Request 18144: Updated resource model reporting to respect multiple roles.

[Dominic Hamon]

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

(Updated Feb. 21, 2014, 1:40 p.m.)


Review request for mesos, Ben Mahler and Vinod Kone.


Bugs: MESOS-692 and MESOS-990
https://issues.apache.org/jira/browse/MESOS-692
https://issues.apache.org/jira/browse/MESOS-990


Repository: mesos-git


Description
---

See summary


Diffs (updated)
-

  src/Makefile.am e02d416e5cb8edf6c44ed05c5785a5084bf02abb 
  src/common/http.hpp PRE-CREATION 
  src/common/http.cpp PRE-CREATION 
  src/master/http.cpp c9412749baeb88e8fc270eeca8710f04da2ac076 
  src/slave/http.cpp 7c4cfba6676124926cfaa665df9fccf68c7dc187 

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


Testing
---

make check.

ran master/slave and checked http://localhost:5050/master/state.json by eye.

ran local/python test framework and watched webui main, framework, and slave 
pages.


Thanks,

Dominic Hamon

Re: Review Request 17476: Added a Sequence abstraction.

[Jie Yu]

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

(Updated Feb. 21, 2014, 9:02 p.m.)


Review request for mesos and Benjamin Hindman.


Repository: mesos-git


Description
---

See summary.

One think I haven't done yet is to make it accepts '_Defer' types. (Just 
curious why Future.onAny can accept defer without doing something special).

Also, we can get rid of the SequencerProcess if we use a mutex to protect 
'last'. Not sure which one is better.

The discard semantics here is a bit tricky. Basically, I wanna support 
discarding a single callback without affecting other callbacks. Also, when the 
Sequencer object is deleted, I wanna discard all the pending callbacks.


Diffs
-

  3rdparty/libprocess/Makefile.am a7d199f 
  3rdparty/libprocess/include/process/sequence.hpp PRE-CREATION 
  3rdparty/libprocess/src/tests/sequence_tests.cpp PRE-CREATION 

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


Testing
---

make check

repeated 1000 times


Thanks,

Jie Yu

Re: Review Request 17476: Added a Sequence abstraction.

[Vinod Kone]

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

Ship it!


LGTM. But I would like BenH to take a look.


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


s/this/these/ ?

s/register/registering/



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


Awesome graph.

Maybe N1, N2 and N3 and T1 T2 and T3 would make it even better to read?

Also consider s/T/F/ so that it is easy to understand that N => 
"next/notifier" and F ==> "future" in the code.



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


s/arrow// ?



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


s/arrow// ?

s/'N'/ previous 'N'/



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


Why is this templated?



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


We typically prefix "_" for methods that are continuations.

Though in this particular case "_add" is not a continuation of "add"




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


"__add" here is a bit confusing because this is not a continuation of 
"_add".



3rdparty/libprocess/src/tests/sequence_tests.cpp


Add a comment on what this test is testing?



3rdparty/libprocess/src/tests/sequence_tests.cpp


Ditto. Comment.



3rdparty/libprocess/src/tests/sequence_tests.cpp


Ditto. Comment.


- Vinod Kone


On Feb. 21, 2014, 5:03 p.m., Jie Yu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17476/
> ---
> 
> (Updated Feb. 21, 2014, 5:03 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Ben Mahler.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> See summary.
> 
> One think I haven't done yet is to make it accepts '_Defer' types. (Just 
> curious why Future.onAny can accept defer without doing something special).
> 
> Also, we can get rid of the SequencerProcess if we use a mutex to protect 
> 'last'. Not sure which one is better.
> 
> The discard semantics here is a bit tricky. Basically, I wanna support 
> discarding a single callback without affecting other callbacks. Also, when 
> the Sequencer object is deleted, I wanna discard all the pending callbacks.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/Makefile.am a7d199f 
>   3rdparty/libprocess/include/process/sequence.hpp PRE-CREATION 
>   3rdparty/libprocess/src/tests/sequence_tests.cpp PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/17476/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> repeated 1000 times
> 
> 
> Thanks,
> 
> Jie Yu
> 
>

[jira] [Commented] (MESOS-1027) IPv6 support

[Dominic Hamon (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908775#comment-13908775
 ] 

Dominic Hamon commented on MESOS-1027:
--

It's a very basic abstraction to reference count a fd. I'm thinking something 
that hides the sockaddr and wraps the C interface to sockets in an API that 
uses Try, etc.

> IPv6 support
> 
>
> Key: MESOS-1027
> URL: https://issues.apache.org/jira/browse/MESOS-1027
> Project: Mesos
>  Issue Type: Improvement
>  Components: framework, libprocess, master, slave
>Reporter: Dominic Hamon
> Fix For: 1.0.0
>
>
> From the CLI down through the various layers of tech we should support IPv6.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Assigned] (MESOS-1025) json_tests fails build

[Vinod Kone (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MESOS-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vinod Kone reassigned MESOS-1025:
-

Assignee: Charlie Carson

[~charliecarson] mind taking a look?

This seems to be the offending commit.

commit dee9bd96e88053ab96c84253578ed332d343fe41
Author: Charlie Carson 
Date:   Thu Feb 20 16:24:09 2014 -0800


> json_tests fails build
> --
>
> Key: MESOS-1025
> URL: https://issues.apache.org/jira/browse/MESOS-1025
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.19.0
>Reporter: Vinod Kone
>Assignee: Charlie Carson
> Fix For: 0.19.0
>
>
> g++ -DPACKAGE_NAME=\"libprocess\" -DPACKAGE_TARNAME=\"libprocess\" 
> -DPACKAGE_VERSION=\"0.0.1\" -DPACKAGE_STRING=\"libprocess\ 0.0.1\" 
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"libprocess\" 
> -DVERSION=\"0.0.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 
> -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 
> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 
> -DLT_OBJDIR=\".libs/\" -DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -I.  -I./stout/include 
> -Iboost-1.53.0 -Iglog-0.3.3/src -Igmock-1.6.0/gtest/include 
> -Igmock-1.6.0/include -Iprotobuf-2.5.0/src-g -g2 -O2 -MT 
> stout_tests-json_tests.o -MD -MP -MF .deps/stout_tests-json_tests.Tpo -c -o 
> stout_tests-json_tests.o `test -f 'stout/tests/json_tests.cpp' || echo 
> './'`stout/tests/json_tests.cpp
> stout/tests/json_tests.cpp: In member function ‘virtual void 
> JsonTest_NumericAssignment_Test::TestBody()’:
> stout/tests/json_tests.cpp:127:3: error: ‘uint64_t’ was not declared in this 
> scope
>uint64_t ui64 = 5;
>^
> stout/tests/json_tests.cpp:127:3: note: suggested alternative:
> In file included from boost-1.53.0/boost/math_fwd.hpp:12:0,
>  from boost-1.53.0/boost/math/common_factor_ct.hpp:13,
>  from boost-1.53.0/boost/variant/variant.hpp:44,
>  from boost-1.53.0/boost/variant.hpp:17,
>  from ./stout/include/stout/json.hpp:26,
>  from stout/tests/json_tests.cpp:9:
> boost-1.53.0/boost/cstdint.hpp:311:42: note:   ‘boost::uint64_t’
>   typedef  ::boost::ulong_long_type   uint64_t;
>   ^
> stout/tests/json_tests.cpp:127:12: error: expected ‘;’ before ‘ui64’
>uint64_t ui64 = 5;
> ^
> stout/tests/json_tests.cpp:128:7: error: ‘ui64’ was not declared in this scope
>v = ui64;



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (MESOS-1027) IPv6 support

[Benjamin Mahler (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908768#comment-13908768
 ] 

Benjamin Mahler commented on MESOS-1027:


[~nekto0n] There is a {{Socket}} class in socket.hpp (I remember a certain 
someone also adding a socket creation wrapper in there ;)).

> IPv6 support
> 
>
> Key: MESOS-1027
> URL: https://issues.apache.org/jira/browse/MESOS-1027
> Project: Mesos
>  Issue Type: Improvement
>  Components: framework, libprocess, master, slave
>Reporter: Dominic Hamon
> Fix For: 1.0.0
>
>
> From the CLI down through the various layers of tech we should support IPv6.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: Review Request 18370: Refactor Cluster::Master::start methods

[Dominic Hamon]

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



src/tests/cluster.hpp


typo: arguments



src/tests/cluster.hpp


indent these lines two more as they're a continuation.



src/tests/cluster.hpp


it seems odd that we're not setting allocatorProcess to the passed in 
allocatorProcess. If this is to extend the lifetime, maybe the allocator should 
own the allocator process?



src/tests/cluster.hpp


CHECK the cast succeeds


- Dominic Hamon


On Feb. 21, 2014, noon, Charlie Carson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18370/
> ---
> 
> (Updated Feb. 21, 2014, noon)
> 
> 
> Review request for mesos, Benjamin Hindman, Ben Mahler, and Vinod Kone.
> 
> 
> Bugs: MESOS-1024
> https://issues.apache.org/jira/browse/MESOS-1024
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Refactor Cluster::Master::start methods
> 
> There are currently two overloads of the Cluster::Masters::start
> function.  One takes a argument of AllocatorProcess* and the other
> does not.  The AllocatorProcess* overload serves two purposes:
> 1) it allows an alternative implementation of AllocatorProcess to be
> passed (i.e. a mock)
> 2) it changes the destruction timing so that the passed in argument
> can outlive the master.
> 
> Beyond that, the two functions are identical.   This changes the
> parameter to be Option and allows all the logic
> to be in one method.  The old function exists for back-compat but
> now simply forward by passing in None() to the other function.
> 
> This is for two purposes:
> 1) reduce code duplication
> 2) position the code so that we can also optionally pass in a mock
>repaier.
> 
> Review: https://reviews.apache.org/r/18370
> 
> 
> Diffs
> -
> 
>   src/tests/cluster.hpp d1bf680ed3f6a0fb16af85a21409d653d44522ca 
> 
> Diff: https://reviews.apache.org/r/18370/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Charlie Carson
> 
>

[jira] [Commented] (MESOS-1027) IPv6 support

[Dominic Hamon (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908758#comment-13908758
 ] 

Dominic Hamon commented on MESOS-1027:
--

Yes - I'd add a socket abstraction (there's a few out there to use for 
inspiration) to wrap the OS level (or process/os::*) calls.

> IPv6 support
> 
>
> Key: MESOS-1027
> URL: https://issues.apache.org/jira/browse/MESOS-1027
> Project: Mesos
>  Issue Type: Improvement
>  Components: framework, libprocess, master, slave
>Reporter: Dominic Hamon
> Fix For: 1.0.0
>
>
> From the CLI down through the various layers of tech we should support IPv6.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Review Request 18370: Refactor Cluster::Master::start methods

[Charlie Carson]

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

Review request for mesos, Benjamin Hindman, Ben Mahler, and Vinod Kone.


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


Repository: mesos-git


Description
---

Refactor Cluster::Master::start methods

There are currently two overloads of the Cluster::Masters::start
function.  One takes a argument of AllocatorProcess* and the other
does not.  The AllocatorProcess* overload serves two purposes:
1) it allows an alternative implementation of AllocatorProcess to be
passed (i.e. a mock)
2) it changes the destruction timing so that the passed in argument
can outlive the master.

Beyond that, the two functions are identical.   This changes the
parameter to be Option and allows all the logic
to be in one method.  The old function exists for back-compat but
now simply forward by passing in None() to the other function.

This is for two purposes:
1) reduce code duplication
2) position the code so that we can also optionally pass in a mock
   repaier.

Review: https://reviews.apache.org/r/18370


Diffs
-

  src/tests/cluster.hpp d1bf680ed3f6a0fb16af85a21409d653d44522ca 

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


Testing
---

make check


Thanks,

Charlie Carson

[jira] [Commented] (MESOS-1027) IPv6 support

[Nikita Vetoshkin (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908743#comment-13908743
 ] 

Nikita Vetoshkin commented on MESOS-1027:
-

+1 on this.
Any suggestions? Looking at the sources - socket creation is pretty low level 
without any wrapping around OS level syscalls. Should there be {{Socket}} class 
in libprocess or some functions returning {{fd}} will be enough?

> IPv6 support
> 
>
> Key: MESOS-1027
> URL: https://issues.apache.org/jira/browse/MESOS-1027
> Project: Mesos
>  Issue Type: Improvement
>  Components: framework, libprocess, master, slave
>Reporter: Dominic Hamon
> Fix For: 1.0.0
>
>
> From the CLI down through the various layers of tech we should support IPv6.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (MESOS-1026) Pull std::tuple / boost::tuples::tuple into Process::tuples namespace

[Benjamin Mahler (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908739#comment-13908739
 ] 

Benjamin Mahler commented on MESOS-1026:


Hey [~tillt], I agree with Vinod that this should live in stout. It's ok for a 
particular stout header to depend on boost. The following already depend on 
boost:
{noformat}
foreach.hpp
hashmap.hpp
hashset.hpp
numify.hpp
preprocessor.hpp
uuid.hpp
{noformat}

Users of stout can choose to not include a particular header if they do not 
want a boost dependency.

> Pull std::tuple / boost::tuples::tuple into Process::tuples namespace
> -
>
> Key: MESOS-1026
> URL: https://issues.apache.org/jira/browse/MESOS-1026
> Project: Mesos
>  Issue Type: Improvement
>  Components: libprocess
>Affects Versions: 0.19.0
>Reporter: Till Toenshoff
>Priority: Minor
>  Labels: boost, c++11, libprocess, tuple
>
> For allowing a smooth transition into the C++11 world, I would like to 
> propose doing a namespace pull-in of std::tuple or boost::tuples::tuple, 
> depending on the availability of C++11. The results should be part of the 
> process::tuples namespace.
> Review-request is upcoming but I wanted to make sure that this improvement 
> could be discussed outside the review-request.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (MESOS-1028) expose internal metrics

[David Robinson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908729#comment-13908729
 ] 

David Robinson commented on MESOS-1028:
---

sgtm

> expose internal metrics
> ---
>
> Key: MESOS-1028
> URL: https://issues.apache.org/jira/browse/MESOS-1028
> Project: Mesos
>  Issue Type: Improvement
>  Components: general
>Reporter: David Robinson
>
> Mesos should export statistics that provide visibility into its internals. 
> This would allow users to detect numerous problem without resorting to 
> trolling log files.
> E.g. export counters of (some of these already exist, most don't):
> cgroup create
> cgroup destroy
> cgroup destroy attempts
> resource offers made
> resource offers accepted
> tasks launched
> tasks destroyed
> tasks lost
> writes to replicated log
> queue length
> export 50th, 90th, 95th, 99th percentile of time taken to:
> start mesos (reach a certain state)
> move tasks between two given states (starting -> started)
> create a cgroup
> destroy a cgroup
> send a message from slave to master
> start a task
> stop a task
> register in zookeeper
> write to the replicated log
> Ideally all these metrics would be exposed via a HTTP+JSON endpoint. See 
> [metrics|http://metrics.codahale.com/getting-started/] for an example (albeit 
> Java) library (or [medida|http://dln.github.io/medida/] for an 
> unmaintained(?) c++ port)
> We've previously seen problems where tasks were stuck in cgroup destroy with 
> >30,000 attempts. Exposing metrics would allow us to easily detect problems 
> like this.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (MESOS-1028) expose internal metrics

[Dominic Hamon (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908718#comment-13908718
 ] 

Dominic Hamon commented on MESOS-1028:
--

Instead of reporting percentiles, it might be better to report the entire 
distribution. Then the receiver of the endpoint can perform further processing 
to determine percentiles or averages as needed.

Building a central service for statistics gathering and publication seems like 
a reasonable approach. The statistics could be both global and per 
master/slave/framework. 

> expose internal metrics
> ---
>
> Key: MESOS-1028
> URL: https://issues.apache.org/jira/browse/MESOS-1028
> Project: Mesos
>  Issue Type: Improvement
>  Components: general
>Reporter: David Robinson
>
> Mesos should export statistics that provide visibility into its internals. 
> This would allow users to detect numerous problem without resorting to 
> trolling log files.
> E.g. export counters of (some of these already exist, most don't):
> cgroup create
> cgroup destroy
> cgroup destroy attempts
> resource offers made
> resource offers accepted
> tasks launched
> tasks destroyed
> tasks lost
> writes to replicated log
> queue length
> export 50th, 90th, 95th, 99th percentile of time taken to:
> start mesos (reach a certain state)
> move tasks between two given states (starting -> started)
> create a cgroup
> destroy a cgroup
> send a message from slave to master
> start a task
> stop a task
> register in zookeeper
> write to the replicated log
> Ideally all these metrics would be exposed via a HTTP+JSON endpoint. See 
> [metrics|http://metrics.codahale.com/getting-started/] for an example (albeit 
> Java) library (or [medida|http://dln.github.io/medida/] for an 
> unmaintained(?) c++ port)
> We've previously seen problems where tasks were stuck in cgroup destroy with 
> >30,000 attempts. Exposing metrics would allow us to easily detect problems 
> like this.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: Review Request 18368: Updated log to use the new interval set abstraction.

[Dominic Hamon]

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



src/log/recover.cpp


Can this be done in one line? Ie, set an initial set in the IntervalSet 
constructor:

IntervalSet positions(Bound::closed(lowestBeginPosition.get()), 
Bound::closed(highestEndPosition.get()));



src/log/replica.cpp


this could be simplified:

return unlearned.contains(position) || holes.contains(position);



src/log/replica.cpp


Is this a valid condition? ie, should we CHECK_GE(from, to) instead?



src/log/replica.cpp


I wonder if these operations would be clearer as named methods 'union' or 
'intersection'


- Dominic Hamon


On Feb. 21, 2014, 11:19 a.m., Jie Yu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18368/
> ---
> 
> (Updated Feb. 21, 2014, 11:19 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Ben Mahler.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> See summary.
> 
> 
> Diffs
> -
> 
>   src/log/catchup.hpp 45dc016 
>   src/log/catchup.cpp bcad278 
>   src/log/coordinator.cpp 96ab121 
>   src/log/recover.cpp 1841f1f 
>   src/log/replica.hpp 08ddcb1 
>   src/log/replica.cpp 746d6c3 
>   src/log/storage.hpp c0eba1b 
>   src/tests/log_tests.cpp 2613e41 
> 
> Diff: https://reviews.apache.org/r/18368/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Jie Yu
> 
>

[jira] [Created] (MESOS-1028) expose internal metrics

[David Robinson (JIRA)]

David Robinson created MESOS-1028:
-

 Summary: expose internal metrics
 Key: MESOS-1028
 URL: https://issues.apache.org/jira/browse/MESOS-1028
 Project: Mesos
  Issue Type: Improvement
  Components: general
Reporter: David Robinson


Mesos should export statistics that provide visibility into its internals. This 
would allow users to detect numerous problem without resorting to trolling log 
files.

E.g. export counters of (some of these already exist, most don't):
cgroup create
cgroup destroy
cgroup destroy attempts
resource offers made
resource offers accepted
tasks launched
tasks destroyed
tasks lost
writes to replicated log
queue length

export 50th, 90th, 95th, 99th percentile of time taken to:
start mesos (reach a certain state)
move tasks between two given states (starting -> started)
create a cgroup
destroy a cgroup
send a message from slave to master
start a task
stop a task
register in zookeeper
write to the replicated log

Ideally all these metrics would be exposed via a HTTP+JSON endpoint. See 
[metrics|http://metrics.codahale.com/getting-started/] for an example (albeit 
Java) library (or [medida|http://dln.github.io/medida/] for an unmaintained(?) 
c++ port)

We've previously seen problems where tasks were stuck in cgroup destroy with 
>30,000 attempts. Exposing metrics would allow us to easily detect problems 
like this.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: Review Request 18333: Updated Makefile.am for the new interval set tests.

[Jie Yu]

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

(Updated Feb. 21, 2014, 7:24 p.m.)


Review request for mesos and Ben Mahler.


Changes
---

Rebased.


Repository: mesos-git


Description
---

See summary. Separated patch for libprocess.


Diffs (updated)
-

  3rdparty/libprocess/3rdparty/Makefile.am 51b118c 

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


Testing
---

make check


Thanks,

Jie Yu

Re: Review Request 18093: Added stout/interval.hpp to model boost interval set.

[Jie Yu]

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

(Updated Feb. 21, 2014, 7:23 p.m.)


Review request for mesos, Benjamin Hindman, Ben Mahler, and Vinod Kone.


Changes
---

Reverted element iteration. Seems that it is needed (see 
https://reviews.apache.org/r/18368/, src/log/catchup.cpp).

Added overloads for IntervalSet. Added tests accordingly.


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


Repository: mesos-git


Description
---

See summary.


Diffs (updated)
-

  3rdparty/libprocess/3rdparty/stout/Makefile.am 5d5a760 
  3rdparty/libprocess/3rdparty/stout/include/stout/interval.hpp PRE-CREATION 
  3rdparty/libprocess/3rdparty/stout/tests/interval_tests.cpp PRE-CREATION 

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


Testing
---

make check

repeat 1000 times for the IntervalTest

Repeating all tests (iteration 100) . . .

Note: Google Test filter = *Interval*
[==] Running 7 tests from 1 test case.
[--] Global test environment set-up.
[--] 7 tests from IntervalTest
[ RUN  ] IntervalTest.Interval
[   OK ] IntervalTest.Interval (0 ms)
[ RUN  ] IntervalTest.Addition
[   OK ] IntervalTest.Addition (0 ms)
[ RUN  ] IntervalTest.Subtraction
[   OK ] IntervalTest.Subtraction (0 ms)
[ RUN  ] IntervalTest.Intersection
[   OK ] IntervalTest.Intersection (0 ms)
[ RUN  ] IntervalTest.LargeInterval
[   OK ] IntervalTest.LargeInterval (0 ms)
[ RUN  ] IntervalTest.ElementIteration
[   OK ] IntervalTest.ElementIteration (0 ms)
[ RUN  ] IntervalTest.IntervalIteration
[   OK ] IntervalTest.IntervalIteration (0 ms)
[--] 7 tests from IntervalTest (0 ms total)

[--] Global test environment tear-down
[==] 7 tests from 1 test case ran. (0 ms total)
[  PASSED  ] 7 tests.


Thanks,

Jie Yu

Review Request 18368: Updated log to use the new interval set abstraction.

[Jie Yu]

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

Review request for mesos, Benjamin Hindman and Ben Mahler.


Repository: mesos-git


Description
---

See summary.


Diffs
-

  src/log/catchup.hpp 45dc016 
  src/log/catchup.cpp bcad278 
  src/log/coordinator.cpp 96ab121 
  src/log/recover.cpp 1841f1f 
  src/log/replica.hpp 08ddcb1 
  src/log/replica.cpp 746d6c3 
  src/log/storage.hpp c0eba1b 
  src/tests/log_tests.cpp 2613e41 

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


Testing
---

make check


Thanks,

Jie Yu

[jira] [Created] (MESOS-1027) IPv6 support

[Dominic Hamon (JIRA)]

Dominic Hamon created MESOS-1027:


 Summary: IPv6 support
 Key: MESOS-1027
 URL: https://issues.apache.org/jira/browse/MESOS-1027
 Project: Mesos
  Issue Type: Improvement
  Components: framework, libprocess, master, slave
Reporter: Dominic Hamon
 Fix For: 1.0.0


>From the CLI down through the various layers of tech we should support IPv6.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: Review Request 18144: Updated resource model reporting to respect multiple roles.

[Vinod Kone]

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

Ship it!


I will get this committed once you fix the new lines. Thanks for your patience.


src/common/http.cpp


new line.



src/common/http.cpp


new line.


- Vinod Kone


On Feb. 21, 2014, 4:36 p.m., Dominic Hamon wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18144/
> ---
> 
> (Updated Feb. 21, 2014, 4:36 p.m.)
> 
> 
> Review request for mesos, Ben Mahler and Vinod Kone.
> 
> 
> Bugs: MESOS-692 and MESOS-990
> https://issues.apache.org/jira/browse/MESOS-692
> https://issues.apache.org/jira/browse/MESOS-990
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> See summary
> 
> 
> Diffs
> -
> 
>   src/Makefile.am e02d416e5cb8edf6c44ed05c5785a5084bf02abb 
>   src/common/http.hpp PRE-CREATION 
>   src/common/http.cpp PRE-CREATION 
>   src/master/http.cpp c9412749baeb88e8fc270eeca8710f04da2ac076 
>   src/slave/http.cpp 7c4cfba6676124926cfaa665df9fccf68c7dc187 
> 
> Diff: https://reviews.apache.org/r/18144/diff/
> 
> 
> Testing
> ---
> 
> make check.
> 
> ran master/slave and checked http://localhost:5050/master/state.json by eye.
> 
> ran local/python test framework and watched webui main, framework, and slave 
> pages.
> 
> 
> Thanks,
> 
> Dominic Hamon
> 
>

Review Request 18360: Include std::tuple or boost::tuples::tuple within the process::tuples namespace.

[TILL TOENSHOFF]

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

Review request for mesos, Adam B, Benjamin Hindman, Ben Mahler, Niklas Nielsen, 
and Vinod Kone.


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


Repository: mesos-git


Description
---

Namespace pull-in of std::tuple or boost::tuples::tuple, depending on the 
availability of C+11. The results are part of the process::tuples namespace.

Example usage including fully qualified namespaces:

process::tuples::tuple tuple = process:tuples::make_tuple(42, true);
int foo = process::tuples::get<0>(tuple);

Additionally, some omissions within Makefile.am have been fixed that left out 
the C++11 specific headers as well as the existing tuples/tuples.hpp and 
tuples/details.hpp.


Diffs
-

  3rdparty/libprocess/Makefile.am a7d199f 
  3rdparty/libprocess/include/process/tuples/tuple.hpp PRE-CREATION 

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


Testing
---

make check (clang c++11, gcc), functional testing


Thanks,

TILL TOENSHOFF

[jira] [Commented] (MESOS-1026) Pull std::tuple / boost::tuples::tuple into Process::tuples namespace

[Till Toenshoff (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908608#comment-13908608
 ] 

Till Toenshoff commented on MESOS-1026:
---

Unfortunately, stout can not be used because it does not have boost as a 
dependency whereas libprocess does rely on boost. 

> Pull std::tuple / boost::tuples::tuple into Process::tuples namespace
> -
>
> Key: MESOS-1026
> URL: https://issues.apache.org/jira/browse/MESOS-1026
> Project: Mesos
>  Issue Type: Improvement
>  Components: libprocess
>Affects Versions: 0.19.0
>Reporter: Till Toenshoff
>Priority: Minor
>  Labels: boost, c++11, libprocess, tuple
>
> For allowing a smooth transition into the C++11 world, I would like to 
> propose doing a namespace pull-in of std::tuple or boost::tuples::tuple, 
> depending on the availability of C++11. The results should be part of the 
> process::tuples namespace.
> Review-request is upcoming but I wanted to make sure that this improvement 
> could be discussed outside the review-request.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: Review Request 18339: Added TaskID validation check.

[Dominic Hamon]

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

(Updated Feb. 21, 2014, 10:21 a.m.)


Review request for mesos, Ben Mahler and Vinod Kone.


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


Repository: mesos-git


Description
---

See summary.

It would be good to have specific unit tests for these validators. I could pull 
out the validation to another file and add unit tests on them.

Final validation for TaskID is awaiting consensus (or as close as we can get) 
on bug/mailing list. I do prefer to be conservative but I don't want to break 
users.


Diffs (updated)
-

  src/master/master.hpp 9d1b56c6b02eb21130f165848297ae0695ac2af7 
  src/master/master.cpp cb46869cd298f3a4fcbe8e4e3fea4bb7c741a0e0 

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


Testing
---

built. ran make check. ran local master/slave/python framework.


Thanks,

Dominic Hamon

[jira] [Commented] (MESOS-1026) Pull std::tuple / boost::tuples::tuple into Process::tuples namespace

[Vinod Kone (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908591#comment-13908591
 ] 

Vinod Kone commented on MESOS-1026:
---

Why would this be in libprocess instead of in stout?

> Pull std::tuple / boost::tuples::tuple into Process::tuples namespace
> -
>
> Key: MESOS-1026
> URL: https://issues.apache.org/jira/browse/MESOS-1026
> Project: Mesos
>  Issue Type: Improvement
>  Components: libprocess
>Affects Versions: 0.19.0
>Reporter: Till Toenshoff
>Priority: Minor
>  Labels: boost, c++11, libprocess, tuple
>
> For allowing a smooth transition into the C++11 world, I would like to 
> propose doing a namespace pull-in of std::tuple or boost::tuples::tuple, 
> depending on the availability of C++11. The results should be part of the 
> process::tuples namespace.
> Review-request is upcoming but I wanted to make sure that this improvement 
> could be discussed outside the review-request.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: Review Request 18361: Implemented MESOS-945: Added hostname attribute to framework, display it in master's web ui

[Dominic Hamon]

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

Ship it!


Ship It!


include/mesos/mesos.proto


remove the trailing whitespace please


- Dominic Hamon


On Feb. 21, 2014, 9:49 a.m., Bernd Mathiske wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18361/
> ---
> 
> (Updated Feb. 21, 2014, 9:49 a.m.)
> 
> 
> Review request for mesos.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> - Added a field to FrameworkInfo in protobuf spec 
> - Added table fields in html of web ui that display framework's hostname for 
> running and terminated frameworks
> - Added line to scheduler constructor that sets framework hostname. This is 
> just about the first centralized piece of code that every framework executes.
> - Refactored scheduler constructor so that code duplication is avoided.
> 
> 
> Diffs
> -
> 
>   include/mesos/mesos.proto 69a4a60 
>   include/mesos/scheduler.hpp 2e4707e 
>   src/master/http.cpp c941274 
>   src/sched/sched.cpp dcb3158 
>   src/slave/http.cpp 7c4cfba 
>   src/webui/master/static/frameworks.html 8686b00 
> 
> Diff: https://reviews.apache.org/r/18361/diff/
> 
> 
> Testing
> ---
> 
> Built (with Clang) and ran local Mesos on Mac. Ran C++ and Java test 
> frameworks. Observed new hostname display in web UI. Built Mesos on Ubuntu 
> 13.10 with gcc 4.8.1.
> 
> 
> Thanks,
> 
> Bernd Mathiske
> 
>

Re: Review Request 18361: Implemented MESOS-945: Added hostname attribute to framework, display it in master's web ui

[Bernd Mathiske]

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

(Updated Feb. 21, 2014, 9:49 a.m.)


Review request for mesos.


Changes
---

Mentioned JIRA topic in title.


Summary (updated)
-

Implemented MESOS-945: Added hostname attribute to framework, display it in 
master's web ui


Repository: mesos-git


Description
---

- Added a field to FrameworkInfo in protobuf spec 
- Added table fields in html of web ui that display framework's hostname for 
running and terminated frameworks
- Added line to scheduler constructor that sets framework hostname. This is 
just about the first centralized piece of code that every framework executes.
- Refactored scheduler constructor so that code duplication is avoided.


Diffs
-

  include/mesos/mesos.proto 69a4a60 
  include/mesos/scheduler.hpp 2e4707e 
  src/master/http.cpp c941274 
  src/sched/sched.cpp dcb3158 
  src/slave/http.cpp 7c4cfba 
  src/webui/master/static/frameworks.html 8686b00 

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


Testing
---

Built (with Clang) and ran local Mesos on Mac. Ran C++ and Java test 
frameworks. Observed new hostname display in web UI. Built Mesos on Ubuntu 
13.10 with gcc 4.8.1.


Thanks,

Bernd Mathiske

Review Request 18361: Added hostname attribute to framework, display it in master's web ui

[Bernd Mathiske]

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

Review request for mesos.


Repository: mesos-git


Description
---

- Added a field to FrameworkInfo in protobuf spec 
- Added table fields in html of web ui that display framework's hostname for 
running and terminated frameworks
- Added line to scheduler constructor that sets framework hostname. This is 
just about the first centralized piece of code that every framework executes.
- Refactored scheduler constructor so that code duplication is avoided.


Diffs
-

  include/mesos/mesos.proto 69a4a60 
  include/mesos/scheduler.hpp 2e4707e 
  src/master/http.cpp c941274 
  src/sched/sched.cpp dcb3158 
  src/slave/http.cpp 7c4cfba 
  src/webui/master/static/frameworks.html 8686b00 

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


Testing
---

Built (with Clang) and ran local Mesos on Mac. Ran C++ and Java test 
frameworks. Observed new hostname display in web UI. Built Mesos on Ubuntu 
13.10 with gcc 4.8.1.


Thanks,

Bernd Mathiske

[jira] [Created] (MESOS-1026) Pull std::tuple / boost::tuples::tuple into Process::tuples namespace

[Till Toenshoff (JIRA)]

Till Toenshoff created MESOS-1026:
-

 Summary: Pull std::tuple / boost::tuples::tuple into 
Process::tuples namespace
 Key: MESOS-1026
 URL: https://issues.apache.org/jira/browse/MESOS-1026
 Project: Mesos
  Issue Type: Improvement
  Components: libprocess
Affects Versions: 0.19.0
Reporter: Till Toenshoff
Priority: Minor


For allowing a smooth transition into the C++11 world, I would like to propose 
doing a namespace pull-in of std::tuple or boost::tuples::tuple, depending on 
the availability of C++11. The results should be part of the process::tuples 
namespace.

Review-request is upcoming but I wanted to make sure that this improvement 
could be discussed outside the review-request.




--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: Review Request 17476: Added a Sequence abstraction.

[Jie Yu]

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

(Updated Feb. 21, 2014, 5:03 p.m.)


Review request for mesos, Benjamin Hindman and Ben Mahler.


Changes
---

Added BenM to the reviewers.


Repository: mesos-git


Description
---

See summary.

One think I haven't done yet is to make it accepts '_Defer' types. (Just 
curious why Future.onAny can accept defer without doing something special).

Also, we can get rid of the SequencerProcess if we use a mutex to protect 
'last'. Not sure which one is better.

The discard semantics here is a bit tricky. Basically, I wanna support 
discarding a single callback without affecting other callbacks. Also, when the 
Sequencer object is deleted, I wanna discard all the pending callbacks.


Diffs
-

  3rdparty/libprocess/Makefile.am a7d199f 
  3rdparty/libprocess/include/process/sequence.hpp PRE-CREATION 
  3rdparty/libprocess/src/tests/sequence_tests.cpp PRE-CREATION 

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


Testing
---

make check

repeated 1000 times


Thanks,

Jie Yu

Re: master and slave talking but not showing up in ui

[Ross Allen]

Joe, do you ever get a line in your slave output that mentions registering
with the master? The output you pasted doesn't show that happening. The
lines should look something like this (bold added by me):

I0221 10:20:13.964689 230219776 slave.cpp:501] New master detected at
master@192.168.1.115:5050

I0221 10:20:13.964833 228073472 status_update_manager.cpp:162] New master
detected at master@192.168.1.115:5050

I0221 10:20:13.964891 230219776 slave.cpp:526] Detecting new master

*I0221 10:20:13.965553 227000320 slave.cpp:544] Registered with master
master@192.168.1.115:5050 ; given slave
ID 201402211020-1929488576-5050-59729-0*

Ross Allen
r...@mesosphere.io


On 21 February 2014 01:52, Joe Stein  wrote:

> from master
>
> root@oss001:/home/jstein# /usr/local/sbin/mesos-master --zk=zk://
> 138.113.121.10:2181,/etc
> I0221 00:49:22.075003 17646 main.cpp:126] Build: 2014-02-06 19:32:44 by
> root
> I0221 00:49:22.075582 17646 main.cpp:167] Starting Mesos master
> I0221 00:49:22.075772 17650 master.cpp:283] Master started on
> 138.138.138.10:5050
> I0221 00:49:22.075848 17650 master.cpp:297] Master ID:
> 201402210049-176851594-5050-17646
> I0221 00:49:22.075932 17650 master.cpp:307] Master allowing unauthenticated
> frameworks to register!!
> 2014-02-21 00:49:22,076:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@658: Client
> environment:zookeeper.version=zookeeper C client 3.3.4
> 2014-02-21 00:49:22,076:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@662: Client
> environment:host.name=oss001
> 2014-02-21 00:49:22,076:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@669: Client
> environment:os.name=Linux
> 2014-02-21 00:49:22,076:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@670: Client
> environment:os.arch=3.8.0-29-generic
> 2014-02-21 00:49:22,076:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@671: Client
> environment:os.version=#42~precise1-Ubuntu SMP Wed Aug 14 16:19:23 UTC 2013
> 2014-02-21 00:49:22,076:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@658: Client
> environment:zookeeper.version=zookeeper C client 3.3.4
> 2014-02-21 00:49:22,076:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@662: Client
> environment:host.name=oss001
> 2014-02-21 00:49:22,076:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@669: Client
> environment:os.name=Linux
> 2014-02-21 00:49:22,076:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@670: Client
> environment:os.arch=3.8.0-29-generic
> 2014-02-21 00:49:22,076:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@671: Client
> environment:os.version=#42~precise1-Ubuntu SMP Wed Aug 14 16:19:23 UTC 2013
> I0221 00:49:22.078568 17649 contender.cpp:121] Joining the ZK group with
> data: 'master@138.138.138.10:5050'
> 2014-02-21 00:49:22,106:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@679: Client
> environment:user.name=jstein
> 2014-02-21 00:49:22,106:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@687: Client
> environment:user.home=/root
> 2014-02-21 00:49:22,106:17646(0x7fbf0e3e4700):ZOO_INFO@log_env@699: Client
> environment:user.dir=/home/jstein
> 2014-02-21 00:49:22,106:17646(0x7fbf0e3e4700):ZOO_INFO@zookeeper_init@727:
> Initiating client connection, host=138.113.121.10:2181,
> sessionTimeout=1 watcher=0x7fbf18045e60 sessionId=0
> sessionPasswd= context=0x7fbeff90 flags=0
> 2014-02-21 00:49:22,106:17646(0x7fbef700):ZOO_INFO@check_events@1585:
> initiated connection to server [138.113.121.10:2181]
> 2014-02-21 00:49:22,108:17646(0x7fbef700):ZOO_INFO@check_events@1632:
> session establishment complete on server [138.113.121.10:2181],
> sessionId=0x14452bb562c0017, negotiated timeout=1
> I0221 00:49:22.109210 17648 group.cpp:310] Group process ((5)@
> 138.138.138.10:5050) connected to ZooKeeper
> I0221 00:49:22.109261 17648 group.cpp:752] Syncing group operations: queue
> size (joins, cancels, datas) = (0, 0, 0)
> I0221 00:49:22.109295 17648 group.cpp:367] Trying to create path '/etc' in
> ZooKeeper
> 2014-02-21 00:49:22,132:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@679: Client
> environment:user.name=jstein
> 2014-02-21 00:49:22,132:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@687: Client
> environment:user.home=/root
> 2014-02-21 00:49:22,132:17646(0x7fbf0f3e6700):ZOO_INFO@log_env@699: Client
> environment:user.dir=/home/jstein
> 2014-02-21 00:49:22,132:17646(0x7fbf0f3e6700):ZOO_INFO@zookeeper_init@727:
> Initiating client connection, host=138.113.121.10:2181,
> sessionTimeout=1 watcher=0x7fbf18045e60 sessionId=0
> sessionPasswd= context=0x7fbf08003360 flags=0
> 2014-02-21 00:49:22,133:17646(0x7fbefeffd700):ZOO_INFO@check_events@1585:
> initiated connection to server [138.113.121.10:2181]
> 2014-02-21 00:49:22,134:17646(0x7fbefeffd700):ZOO_INFO@check_events@1632:
> session establishment complete on server [138.113.121.10:2181],
> sessionId=0x14452bb562c0018, negotiated timeout=1
> I0221 00:49:22.134649 17650 group.cpp:310] Group process ((3)@
> 138.138.138.10:5050) connected to ZooKeeper
> I0221 00:49:22.134721 17650 group.cpp:752] Syncing group operations: queue
> size (joins, cancels, datas) = (1, 0, 0)
> I0221 00:4

Re: Review Request 18144: Updated resource model reporting to respect multiple roles.

[Dominic Hamon]

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

(Updated Feb. 21, 2014, 8:36 a.m.)


Review request for mesos, Ben Mahler and Vinod Kone.


Bugs: MESOS-692 and MESOS-990
https://issues.apache.org/jira/browse/MESOS-692
https://issues.apache.org/jira/browse/MESOS-990


Repository: mesos-git


Description
---

See summary


Diffs (updated)
-

  src/Makefile.am e02d416e5cb8edf6c44ed05c5785a5084bf02abb 
  src/common/http.hpp PRE-CREATION 
  src/common/http.cpp PRE-CREATION 
  src/master/http.cpp c9412749baeb88e8fc270eeca8710f04da2ac076 
  src/slave/http.cpp 7c4cfba6676124926cfaa665df9fccf68c7dc187 

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


Testing
---

make check.

ran master/slave and checked http://localhost:5050/master/state.json by eye.

ran local/python test framework and watched webui main, framework, and slave 
pages.


Thanks,

Dominic Hamon

Review Request 18339: Added TaskID validation check.

[Dominic Hamon]

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

Review request for mesos, Ben Mahler and Vinod Kone.


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


Repository: mesos-git


Description
---

See summary.

It would be good to have specific unit tests for these validators. I could pull 
out the validation to another file and add unit tests on them.

Final validation for TaskID is awaiting consensus (or as close as we can get) 
on bug/mailing list. I do prefer to be conservative but I don't want to break 
users.


Diffs
-

  src/master/master.cpp cb46869cd298f3a4fcbe8e4e3fea4bb7c741a0e0 

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


Testing
---

built. ran make check. ran local master/slave/python framework.


Thanks,

Dominic Hamon

Re: Review Request 18307: Fixed compile error MESOS-1009, plus subsequent compile errors

[Bernd Mathiske]

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

(Updated Feb. 21, 2014, 1:03 a.m.)


Review request for mesos.


Changes
---

Fixed typo.


Repository: mesos-git


Description
---

Fix for MESOS-1009 plus fixes for all subsequent compile errors that were 
masked by the first one reported in MESOS-1009. Result: Mesos compiles on 
Ubuntu 13.10 with Clang 3.5. Original problem was a coding mistake in the glog 
library from Google. Appended diff to the glog lib patch file already in Mesos.

The additional errors found and fixed are:

../../3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp:730:18: error: 
'va_start' has undefined behavior with
  reference types [-Werror,-Wvarargs]
  va_start(args, fmt);
 ^
/root/clang/build/Release/bin/../lib/clang/3.5/include/stdarg.h:33:52: note: 
expanded from macro 'va_start'
#define va_start(ap, param) __builtin_va_start(ap, param)
   ^
../../3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp:727:60: note: 
parameter of type 'const std::string &'
  (aka 'const basic_string &') is declared here
inline Try shell(std::ostream* os, const std::string& fmt, ...)


——

../../3rdparty/libprocess/3rdparty/stout/include/stout/format.hpp:402:18: 
error: 'va_start' has undefined behavior with
  reference types [-Werror,-Wvarargs]
  va_start(args, fmt);
 ^
/root/clang/build/Release/bin/../lib/clang/3.5/include/stdarg.h:33:52: note: 
expanded from macro 'va_start'
#define va_start(ap, param) __builtin_va_start(ap, param)
   ^
../../3rdparty/libprocess/3rdparty/stout/include/stout/format.hpp:399:51: note: 
parameter of type 'const std::string &'
  (aka 'const basic_string &') is declared here
inline Try format(const std::string& fmt, ...)


——

../../src/messages/state.hpp:19:9: error: '__MESSAGE_STATE_HPP__' is used as a 
header guard here, followed by #define
  of a different macro [-Werror,-Wheader-guard]
#ifndef __MESSAGE_STATE_HPP__
^
../../src/messages/state.hpp:20:9: note: '__MESSAGES_STATE_HPP__' is defined 
here; did you mean
  '__MESSAGE_STATE_HPP__'?
#define __MESSAGES_STATE_HPP__
^~
__MESSAGE_STATE_HPP__


——


In file included from ../../src/java/jni/convert.cpp:32:
../../src/jvm/jvm.hpp:473:18: error: 'va_start' has undefined behavior with 
reference types [-Werror,-Wvarargs]
  va_start(args, method);
 ^
/root/clang/build/Release/bin/../lib/clang/3.5/include/stdarg.h:33:52: note: 
expanded from macro 'va_start'
#define va_start(ap, param) __builtin_va_start(ap, param)
   ^
../../src/jvm/jvm.hpp:470:53: note: parameter of type 'const Jvm::Method &' is 
declared here
T Jvm::invoke(const jobject receiver, const Method& method, ...)
^
../../src/jvm/jvm.hpp:488:18: error: 'va_start' has undefined behavior with 
reference types [-Werror,-Wvarargs]
  va_start(args, method);
 ^
/root/clang/build/Release/bin/../lib/clang/3.5/include/stdarg.h:33:52: note: 
expanded from macro 'va_start'
#define va_start(ap, param) __builtin_va_start(ap, param)
   ^
../../src/jvm/jvm.hpp:485:35: note: parameter of type 'const Jvm::Method &' is 
declared here
T Jvm::invokeStatic(const Method& method, ...)
  ^


Diffs (updated)
-

  3rdparty/libprocess/3rdparty/glog-0.3.3.patch 974f9f5 
  3rdparty/libprocess/3rdparty/stout/include/stout/format.hpp 3eadaef 
  3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp bba6f43 
  src/jvm/jvm.hpp b4dff78 
  src/jvm/jvm.cpp 6eb3a34 
  src/messages/state.hpp 6245499 

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


Testing
---

make succeeded on Ubuntu 13.10 with Clang 3.5 and on Mac OS X 10.9 with Clang 
3.2. "make check" OK on Mac, small problem may remain on Ubuntu, suspect 
unrelated issue. C test framework OK on Mac, but not on Ubuntu: all tasks end 
up in state 5. Suspect an unrelated issue here. Java test framework runs on 
both platforms.


Thanks,

Bernd Mathiske