date:20140912


[ 
https://issues.apache.org/jira/browse/MESOS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131489#comment-14131489
 ] 

Timothy St. Clair commented on MESOS-1776:
--

This is a bug in the logic, but there are few dependencies that can be treated 
--without-package. 


 --without-PACKAGE will set incorrect dependency prefix
 --

 Key: MESOS-1776
 URL: https://issues.apache.org/jira/browse/MESOS-1776
 Project: Mesos
  Issue Type: Bug
  Components: build
Affects Versions: 0.20.0
Reporter: Kamil Domański
  Labels: build

 When disabling a particular bundled dependency with *--without-PACKAGE*, the 
 build scripts of both Mesos and libprocess will set a corresponding variable 
 to no. This is later treated as prefix under which to search for the 
 package.
 For example, with *--without-protobuf*, the script will search for *protoc* 
 under *no/bin* and obviously fail. I would propose to get rid of these 
 prefixes entirely and instead search in default locations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MESOS-1764) Build Fixes from 0.20 release


[ 
https://issues.apache.org/jira/browse/MESOS-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128940#comment-14128940
 ] 

Timothy St. Clair edited comment on MESOS-1764 at 9/12/14 1:00 PM:
---

fix git clean -xdf on leveldb folder
-reviews.apache.org/r/25508-

commit f2bcfc33598cfb7bd36ea761f37b5e07881d32e2
Author: Timothy St. Clair tstcl...@redhat.com
Date:   Wed Sep 10 13:58:24 2014 -0500



was (Author: tstclair):
fix git clean -xdf on leveldb folder
-reviews.apache.org/r/25508-

 Build Fixes from 0.20 release
 -

 Key: MESOS-1764
 URL: https://issues.apache.org/jira/browse/MESOS-1764
 Project: Mesos
  Issue Type: Bug
  Components: build
Affects Versions: 0.20.0
Reporter: Timothy St. Clair
Assignee: Timothy St. Clair

 This ticket is a catch all for minor issues caught during a rebase and 
 testing.
 + Add package configuration file to deployment
 + Updates deploy_dir from localstatedir to sysconfdir



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MESOS-1764) Build Fixes from 0.20 release


[ 
https://issues.apache.org/jira/browse/MESOS-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14125739#comment-14125739
 ] 

Timothy St. Clair edited comment on MESOS-1764 at 9/12/14 1:00 PM:
---

update the deployment directory: 
-reviews.apache.org/r/25447/-

Need to track to determine if deprecation is needed. 

commit fd798ffbeecee644b4674a9149c38d563bfa044e
Author: Timothy St. Clair tstcl...@redhat.com
Date:   Tue Sep 9 13:28:10 2014 -0500


was (Author: tstclair):
update the deployment directory: 
-reviews.apache.org/r/25447/-

Need to track to determine if deprecation is needed. 

 Build Fixes from 0.20 release
 -

 Key: MESOS-1764
 URL: https://issues.apache.org/jira/browse/MESOS-1764
 Project: Mesos
  Issue Type: Bug
  Components: build
Affects Versions: 0.20.0
Reporter: Timothy St. Clair
Assignee: Timothy St. Clair

 This ticket is a catch all for minor issues caught during a rebase and 
 testing.
 + Add package configuration file to deployment
 + Updates deploy_dir from localstatedir to sysconfdir



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MESOS-1764) Build Fixes from 0.20 release


[ 
https://issues.apache.org/jira/browse/MESOS-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121966#comment-14121966
 ] 

Timothy St. Clair edited comment on MESOS-1764 at 9/12/14 1:01 PM:
---

package config file
-reviews.apache.org/r/25355/-

commit 08e3d9d8866bc5038b085775830214ef957480fe
Author: Timothy St. Clair tstcl...@redhat.com
Date:   Fri Sep 5 09:13:33 2014 -0500



was (Author: tstclair):
package config file
-reviews.apache.org/r/25355/-

 Build Fixes from 0.20 release
 -

 Key: MESOS-1764
 URL: https://issues.apache.org/jira/browse/MESOS-1764
 Project: Mesos
  Issue Type: Bug
  Components: build
Affects Versions: 0.20.0
Reporter: Timothy St. Clair
Assignee: Timothy St. Clair

 This ticket is a catch all for minor issues caught during a rebase and 
 testing.
 + Add package configuration file to deployment
 + Updates deploy_dir from localstatedir to sysconfdir



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MESOS-1776) --without-PACKAGE will set incorrect dependency prefix


[ 
https://issues.apache.org/jira/browse/MESOS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131489#comment-14131489
 ] 

Timothy St. Clair edited comment on MESOS-1776 at 9/12/14 2:09 PM:
---

This is a bug in the logic, but there are few dependencies that can be treated 
--without-package. 

Is the intent to build against system dependencies or disable functionality?



was (Author: tstclair):
This is a bug in the logic, but there are few dependencies that can be treated 
--without-package. 


 --without-PACKAGE will set incorrect dependency prefix
 --

 Key: MESOS-1776
 URL: https://issues.apache.org/jira/browse/MESOS-1776
 Project: Mesos
  Issue Type: Bug
  Components: build
Affects Versions: 0.20.0
Reporter: Kamil Domański
  Labels: build

 When disabling a particular bundled dependency with *--without-PACKAGE*, the 
 build scripts of both Mesos and libprocess will set a corresponding variable 
 to no. This is later treated as prefix under which to search for the 
 package.
 For example, with *--without-protobuf*, the script will search for *protoc* 
 under *no/bin* and obviously fail. I would propose to get rid of these 
 prefixes entirely and instead search in default locations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-1778) Provide an option to validate flag value in stout/flags.


[ 
https://issues.apache.org/jira/browse/MESOS-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131589#comment-14131589
 ] 

Kamil Domański commented on MESOS-1778:
---

[~alex-mesos], I see a lot of value checks after each call to Flags::load( ).

 Provide an option to validate flag value in stout/flags. 
 -

 Key: MESOS-1778
 URL: https://issues.apache.org/jira/browse/MESOS-1778
 Project: Mesos
  Issue Type: Improvement
  Components: stout
Reporter: Alexander Rukletsov
Priority: Minor

 Currently we can provide the default value for a flag, but cannot check if 
 the flag is set to a reasonable value and, e.g., issue a warning. Passing an 
 optional lambda checker to {{FlagBase::add()}} can be a possible solution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-1775) Libprocess wants source for unbundled gmock


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

Kamil Domański updated MESOS-1775:
--
Target Version/s: 1.0.0, 0.21.0  (was: 1.0.0, 0.20.1)

 Libprocess wants source for unbundled gmock
 ---

 Key: MESOS-1775
 URL: https://issues.apache.org/jira/browse/MESOS-1775
 Project: Mesos
  Issue Type: Bug
  Components: build, libprocess
Affects Versions: 0.20.0
 Environment: Gentoo Linux
 ./configure --disable-bundled
Reporter: Kamil Domański
Priority: Minor
  Labels: build

 *gmock* is installed on my system. Yet with *--disable-bundled* the 
 libprocess configuration script is still searching for *gmock-all.cc* instead 
 of just the headers and libraries.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-1776) --without-PACKAGE will set incorrect dependency prefix


[ 
https://issues.apache.org/jira/browse/MESOS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131665#comment-14131665
 ] 

Timothy St. Clair commented on MESOS-1776:
--

Then you would use '--disable-bundled' or specify '--with-package' without 
args. 

--without-package means 'disable feature that uses dependency' 

 --without-PACKAGE will set incorrect dependency prefix
 --

 Key: MESOS-1776
 URL: https://issues.apache.org/jira/browse/MESOS-1776
 Project: Mesos
  Issue Type: Bug
  Components: build
Affects Versions: 0.20.0
Reporter: Kamil Domański
  Labels: build

 When disabling a particular bundled dependency with *--without-PACKAGE*, the 
 build scripts of both Mesos and libprocess will set a corresponding variable 
 to no. This is later treated as prefix under which to search for the 
 package.
 For example, with *--without-protobuf*, the script will search for *protoc* 
 under *no/bin* and obviously fail. I would propose to get rid of these 
 prefixes entirely and instead search in default locations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MESOS-1776) --without-PACKAGE will set incorrect dependency prefix


[ 
https://issues.apache.org/jira/browse/MESOS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131665#comment-14131665
 ] 

Timothy St. Clair edited comment on MESOS-1776 at 9/12/14 3:29 PM:
---

Then you would use '--disable-bundled' or specify ' --with-package' without 
args. 

--without-package means 'disable feature that uses dependency' 


was (Author: tstclair):
Then you would use '--disable-bundled' or specify '--with-package' without 
args. 

--without-package means 'disable feature that uses dependency' 

 --without-PACKAGE will set incorrect dependency prefix
 --

 Key: MESOS-1776
 URL: https://issues.apache.org/jira/browse/MESOS-1776
 Project: Mesos
  Issue Type: Bug
  Components: build
Affects Versions: 0.20.0
Reporter: Kamil Domański
  Labels: build

 When disabling a particular bundled dependency with *--without-PACKAGE*, the 
 build scripts of both Mesos and libprocess will set a corresponding variable 
 to no. This is later treated as prefix under which to search for the 
 package.
 For example, with *--without-protobuf*, the script will search for *protoc* 
 under *no/bin* and obviously fail. I would propose to get rid of these 
 prefixes entirely and instead search in default locations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-1787) Expose historical executor statistics / time series data over slave endpoint


[ 
https://issues.apache.org/jira/browse/MESOS-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131717#comment-14131717
 ] 

Dominic Hamon commented on MESOS-1787:
--

There might be some use in looking at 
https://github.com/apache/mesos/tree/master/3rdparty/libprocess/include/process/metrics
 and 
https://github.com/apache/mesos/blob/master/3rdparty/libprocess/include/process/statistics.hpp
 which are the things we use to expose metrics for the rest of the code-base.

 Expose historical executor statistics / time series data over slave endpoint
 

 Key: MESOS-1787
 URL: https://issues.apache.org/jira/browse/MESOS-1787
 Project: Mesos
  Issue Type: Improvement
  Components: slave
Reporter: Niklas Quarfot Nielsen

 Per https://github.com/apache/mesos/blob/master/src/slave/monitor.hpp#L118 , 
 we already collect historical statistics but do not expose them over the 
 monitor http endpoints yet.
 As [~bmahler] suggested, this would involve adding archive.json, presenting 
 them (https://github.com/apache/mesos/blob/master/src/slave/monitor.cpp#L223) 
  and preferably ways to query the available samples (along the lines of 
 https://github.com/apache/mesos/blob/master/src/master/http.cpp#L776)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MESOS-1776) --without-PACKAGE will set incorrect dependency prefix


[ 
https://issues.apache.org/jira/browse/MESOS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131736#comment-14131736
 ] 

Timothy St. Clair edited comment on MESOS-1776 at 9/12/14 4:48 PM:
---

--with-package= is the resolved mechanics for the situation described, and is 
consistent.

If you wanted to, we could add an option such as '--disable-bundled=soft|hard'
Where soft fails over to bundled if dependency is not found, while hard just 
fails when not found.

Also --without-package should probably yield a meaningful error message.  



was (Author: tstclair):
--with-package= is the resolved mechanics for the situation described, and is 
consistent.

If you wanted to, we could add an option such as '--disable-bundled=soft|hard'
Where soft fails over to bundled if dependency is not found. 

Also --without-package should probably yield a meaningful error message.  


 --without-PACKAGE will set incorrect dependency prefix
 --

 Key: MESOS-1776
 URL: https://issues.apache.org/jira/browse/MESOS-1776
 Project: Mesos
  Issue Type: Bug
  Components: build
Affects Versions: 0.20.0
Reporter: Kamil Domański
  Labels: build

 When disabling a particular bundled dependency with *--without-PACKAGE*, the 
 build scripts of both Mesos and libprocess will set a corresponding variable 
 to no. This is later treated as prefix under which to search for the 
 package.
 For example, with *--without-protobuf*, the script will search for *protoc* 
 under *no/bin* and obviously fail. I would propose to get rid of these 
 prefixes entirely and instead search in default locations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-1776) --without-PACKAGE will set incorrect dependency prefix


[ 
https://issues.apache.org/jira/browse/MESOS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131736#comment-14131736
 ] 

Timothy St. Clair commented on MESOS-1776:
--

--with-package= is the resolved mechanics for the situation described, and is 
consistent.

If you wanted to, we could add an option such as '--disable-bundled=soft|hard'
Where soft fails over to bundled if dependency is not found. 

Also --without-package should probably yield a meaningful error message.  


 --without-PACKAGE will set incorrect dependency prefix
 --

 Key: MESOS-1776
 URL: https://issues.apache.org/jira/browse/MESOS-1776
 Project: Mesos
  Issue Type: Bug
  Components: build
Affects Versions: 0.20.0
Reporter: Kamil Domański
  Labels: build

 When disabling a particular bundled dependency with *--without-PACKAGE*, the 
 build scripts of both Mesos and libprocess will set a corresponding variable 
 to no. This is later treated as prefix under which to search for the 
 package.
 For example, with *--without-protobuf*, the script will search for *protoc* 
 under *no/bin* and obviously fail. I would propose to get rid of these 
 prefixes entirely and instead search in default locations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-1776) --without-PACKAGE will set incorrect dependency prefix


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

Timothy St. Clair updated MESOS-1776:
-
Target Version/s: 0.21.0  (was: 1.0.0, 0.21.0, 0.20.1)

 --without-PACKAGE will set incorrect dependency prefix
 --

 Key: MESOS-1776
 URL: https://issues.apache.org/jira/browse/MESOS-1776
 Project: Mesos
  Issue Type: Bug
  Components: build
Affects Versions: 0.20.0
Reporter: Kamil Domański
  Labels: build

 When disabling a particular bundled dependency with *--without-PACKAGE*, the 
 build scripts of both Mesos and libprocess will set a corresponding variable 
 to no. This is later treated as prefix under which to search for the 
 package.
 For example, with *--without-protobuf*, the script will search for *protoc* 
 under *no/bin* and obviously fail. I would propose to get rid of these 
 prefixes entirely and instead search in default locations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-1775) Libprocess wants source for unbundled gmock


[ 
https://issues.apache.org/jira/browse/MESOS-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131745#comment-14131745
 ] 

Timothy St. Clair commented on MESOS-1775:
--

gmock packaging has turned to be a rebuild package.  This is consistent across 
both Debian and Red Hat distributions. 


 Libprocess wants source for unbundled gmock
 ---

 Key: MESOS-1775
 URL: https://issues.apache.org/jira/browse/MESOS-1775
 Project: Mesos
  Issue Type: Bug
  Components: build, libprocess
Affects Versions: 0.20.0
 Environment: Gentoo Linux
 ./configure --disable-bundled
Reporter: Kamil Domański
Priority: Minor
  Labels: build

 *gmock* is installed on my system. Yet with *--disable-bundled* the 
 libprocess configuration script is still searching for *gmock-all.cc* instead 
 of just the headers and libraries.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MESOS-1775) Libprocess wants source for unbundled gmock


[ 
https://issues.apache.org/jira/browse/MESOS-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131745#comment-14131745
 ] 

Timothy St. Clair edited comment on MESOS-1775 at 9/12/14 5:09 PM:
---

gmock packaging has turned to be a rebuild package.  This is consistent across 
both Debian and Red Hat distributions, and has been outlined by upstream. 



was (Author: tstclair):
gmock packaging has turned to be a rebuild package.  This is consistent across 
both Debian and Red Hat distributions. 


 Libprocess wants source for unbundled gmock
 ---

 Key: MESOS-1775
 URL: https://issues.apache.org/jira/browse/MESOS-1775
 Project: Mesos
  Issue Type: Bug
  Components: build, libprocess
Affects Versions: 0.20.0
 Environment: Gentoo Linux
 ./configure --disable-bundled
Reporter: Kamil Domański
Priority: Minor
  Labels: build

 *gmock* is installed on my system. Yet with *--disable-bundled* the 
 libprocess configuration script is still searching for *gmock-all.cc* instead 
 of just the headers and libraries.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-1776) --without-PACKAGE will set incorrect dependency prefix


[ 
https://issues.apache.org/jira/browse/MESOS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131760#comment-14131760
 ] 

Kamil Domański commented on MESOS-1776:
---

It might very well be the only case where it fails, but {{./configure 
--with-protobuf=}} will call {{AC_CHECK_TOOL([PROTOCOMPILER_TEST]\, [protoc], 
[], [$PROTOBUFPREFIX/bin])}} where {{PROTOBUFPREFIX}} is empty, thus only 
searching in {{/bin}} and failing.

 --without-PACKAGE will set incorrect dependency prefix
 --

 Key: MESOS-1776
 URL: https://issues.apache.org/jira/browse/MESOS-1776
 Project: Mesos
  Issue Type: Bug
  Components: build
Affects Versions: 0.20.0
Reporter: Kamil Domański
  Labels: build

 When disabling a particular bundled dependency with *--without-PACKAGE*, the 
 build scripts of both Mesos and libprocess will set a corresponding variable 
 to no. This is later treated as prefix under which to search for the 
 package.
 For example, with *--without-protobuf*, the script will search for *protoc* 
 under *no/bin* and obviously fail. I would propose to get rid of these 
 prefixes entirely and instead search in default locations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MESOS-1776) --without-PACKAGE will set incorrect dependency prefix


[ 
https://issues.apache.org/jira/browse/MESOS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131768#comment-14131768
 ] 

Kamil Domański edited comment on MESOS-1776 at 9/12/14 5:18 PM:


The case above aside, {{\--with-package=}} seems to work, but 
{{--without-PACKAGE}} is still advertised by {{./configure --help}} thus a 
source of misinformation.


was (Author: kdomanski):
The case above aside, {{--with-package=}} seems to work, but 
{{--without-PACKAGE}} is still advertised by {{./configure --help}} thus a 
source of misinformation.

 --without-PACKAGE will set incorrect dependency prefix
 --

 Key: MESOS-1776
 URL: https://issues.apache.org/jira/browse/MESOS-1776
 Project: Mesos
  Issue Type: Bug
  Components: build
Affects Versions: 0.20.0
Reporter: Kamil Domański
  Labels: build

 When disabling a particular bundled dependency with *--without-PACKAGE*, the 
 build scripts of both Mesos and libprocess will set a corresponding variable 
 to no. This is later treated as prefix under which to search for the 
 package.
 For example, with *--without-protobuf*, the script will search for *protoc* 
 under *no/bin* and obviously fail. I would propose to get rid of these 
 prefixes entirely and instead search in default locations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MESOS-1776) --without-PACKAGE will set incorrect dependency prefix


[ 
https://issues.apache.org/jira/browse/MESOS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131768#comment-14131768
 ] 

Kamil Domański edited comment on MESOS-1776 at 9/12/14 5:18 PM:


The case above aside, {{\-\-with-package=}} seems to work, but 
{{--without-PACKAGE}} is still advertised by {{./configure --help}} thus a 
source of misinformation.


was (Author: kdomanski):
The case above aside, {{\--with-package=}} seems to work, but 
{{--without-PACKAGE}} is still advertised by {{./configure --help}} thus a 
source of misinformation.

 --without-PACKAGE will set incorrect dependency prefix
 --

 Key: MESOS-1776
 URL: https://issues.apache.org/jira/browse/MESOS-1776
 Project: Mesos
  Issue Type: Bug
  Components: build
Affects Versions: 0.20.0
Reporter: Kamil Domański
  Labels: build

 When disabling a particular bundled dependency with *--without-PACKAGE*, the 
 build scripts of both Mesos and libprocess will set a corresponding variable 
 to no. This is later treated as prefix under which to search for the 
 package.
 For example, with *--without-protobuf*, the script will search for *protoc* 
 under *no/bin* and obviously fail. I would propose to get rid of these 
 prefixes entirely and instead search in default locations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-1776) --without-PACKAGE will set incorrect dependency prefix


[ 
https://issues.apache.org/jira/browse/MESOS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131779#comment-14131779
 ] 

Timothy St. Clair commented on MESOS-1776:
--

To clarify: 

1.) --with-protobuf=emptysting currently doesn't default to /usr
2.) remove --without-package description. 

possibly 
3.) --disable-bundled=soft|hard  

Did you want to submit a patch, or shall I?

 --without-PACKAGE will set incorrect dependency prefix
 --

 Key: MESOS-1776
 URL: https://issues.apache.org/jira/browse/MESOS-1776
 Project: Mesos
  Issue Type: Bug
  Components: build
Affects Versions: 0.20.0
Reporter: Kamil Domański
  Labels: build

 When disabling a particular bundled dependency with *--without-PACKAGE*, the 
 build scripts of both Mesos and libprocess will set a corresponding variable 
 to no. This is later treated as prefix under which to search for the 
 package.
 For example, with *--without-protobuf*, the script will search for *protoc* 
 under *no/bin* and obviously fail. I would propose to get rid of these 
 prefixes entirely and instead search in default locations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MESOS-1775) Libprocess wants source for unbundled gmock


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

Timothy St. Clair closed MESOS-1775.

  Resolution: Not a Problem
Target Version/s:   (was: 1.0.0, 0.21.0)

 Libprocess wants source for unbundled gmock
 ---

 Key: MESOS-1775
 URL: https://issues.apache.org/jira/browse/MESOS-1775
 Project: Mesos
  Issue Type: Bug
  Components: build, libprocess
Affects Versions: 0.20.0
 Environment: Gentoo Linux
 ./configure --disable-bundled
Reporter: Kamil Domański
Priority: Minor
  Labels: build

 *gmock* is installed on my system. Yet with *--disable-bundled* the 
 libprocess configuration script is still searching for *gmock-all.cc* instead 
 of just the headers and libraries.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-1783) MasterTest.LaunchDuplicateOfferTest is flaky

2014-09-12 Thread Niklas Quarfot Nielsen (JIRA)


[ 
https://issues.apache.org/jira/browse/MESOS-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131820#comment-14131820
 ] 

Niklas Quarfot Nielsen commented on MESOS-1783:
---

https://reviews.apache.org/r/25588/

 MasterTest.LaunchDuplicateOfferTest is flaky
 

 Key: MESOS-1783
 URL: https://issues.apache.org/jira/browse/MESOS-1783
 Project: Mesos
  Issue Type: Bug
  Components: test
Affects Versions: 0.20.0
 Environment: ubuntu-14.04-gcc Jenkins VM
Reporter: Yan Xu

 {noformat:title=}
 [ RUN  ] MasterTest.LaunchDuplicateOfferTest
 Using temporary directory '/tmp/MasterTest_LaunchDuplicateOfferTest_3ifzmg'
 I0909 22:46:59.212977 21883 leveldb.cpp:176] Opened db in 20.307533ms
 I0909 22:46:59.219717 21883 leveldb.cpp:183] Compacted db in 6.470397ms
 I0909 22:46:59.219925 21883 leveldb.cpp:198] Created db iterator in 5571ns
 I0909 22:46:59.220100 21883 leveldb.cpp:204] Seeked to beginning of db in 
 1365ns
 I0909 22:46:59.220268 21883 leveldb.cpp:273] Iterated through 0 keys in the 
 db in 658ns
 I0909 22:46:59.220448 21883 replica.cpp:741] Replica recovered with log 
 positions 0 - 0 with 1 holes and 0 unlearned
 I0909 22:46:59.220855 21903 recover.cpp:425] Starting replica recovery
 I0909 22:46:59.221103 21903 recover.cpp:451] Replica is in EMPTY status
 I0909 22:46:59.221626 21903 replica.cpp:638] Replica in EMPTY status received 
 a broadcasted recover request
 I0909 22:46:59.221914 21903 recover.cpp:188] Received a recover response from 
 a replica in EMPTY status
 I0909 22:46:59.04 21903 recover.cpp:542] Updating replica status to 
 STARTING
 I0909 22:46:59.232590 21900 master.cpp:286] Master 
 20140909-224659-16842879-44263-21883 (trusty) started on 127.0.1.1:44263
 I0909 22:46:59.233278 21900 master.cpp:332] Master only allowing 
 authenticated frameworks to register
 I0909 22:46:59.233543 21900 master.cpp:337] Master only allowing 
 authenticated slaves to register
 I0909 22:46:59.233934 21900 credentials.hpp:36] Loading credentials for 
 authentication from 
 '/tmp/MasterTest_LaunchDuplicateOfferTest_3ifzmg/credentials'
 I0909 22:46:59.236431 21900 master.cpp:366] Authorization enabled
 I0909 22:46:59.237522 21898 hierarchical_allocator_process.hpp:299] 
 Initializing hierarchical allocator process with master : 
 master@127.0.1.1:44263
 I0909 22:46:59.237877 21904 master.cpp:120] No whitelist given. Advertising 
 offers for all slaves
 I0909 22:46:59.238723 21903 leveldb.cpp:306] Persisting metadata (8 bytes) to 
 leveldb took 16.245391ms
 I0909 22:46:59.238916 21903 replica.cpp:320] Persisted replica status to 
 STARTING
 I0909 22:46:59.239203 21903 recover.cpp:451] Replica is in STARTING status
 I0909 22:46:59.239724 21903 replica.cpp:638] Replica in STARTING status 
 received a broadcasted recover request
 I0909 22:46:59.239967 21903 recover.cpp:188] Received a recover response from 
 a replica in STARTING status
 I0909 22:46:59.240304 21903 recover.cpp:542] Updating replica status to VOTING
 I0909 22:46:59.240684 21900 master.cpp:1212] The newly elected leader is 
 master@127.0.1.1:44263 with id 20140909-224659-16842879-44263-21883
 I0909 22:46:59.240846 21900 master.cpp:1225] Elected as the leading master!
 I0909 22:46:59.241149 21900 master.cpp:1043] Recovering from registrar
 I0909 22:46:59.241509 21898 registrar.cpp:313] Recovering registrar
 I0909 22:46:59.248440 21903 leveldb.cpp:306] Persisting metadata (8 bytes) to 
 leveldb took 7.864221ms
 I0909 22:46:59.248644 21903 replica.cpp:320] Persisted replica status to 
 VOTING
 I0909 22:46:59.248846 21903 recover.cpp:556] Successfully joined the Paxos 
 group
 I0909 22:46:59.249330 21897 log.cpp:656] Attempting to start the writer
 I0909 22:46:59.249809 21897 replica.cpp:474] Replica received implicit 
 promise request with proposal 1
 I0909 22:46:59.250075 21903 recover.cpp:440] Recover process terminated
 I0909 22:46:59.258286 21897 leveldb.cpp:306] Persisting metadata (8 bytes) to 
 leveldb took 8.292514ms
 I0909 22:46:59.258489 21897 replica.cpp:342] Persisted promised to 1
 I0909 22:46:59.258848 21897 coordinator.cpp:230] Coordinator attemping to 
 fill missing position
 I0909 22:46:59.259454 21897 replica.cpp:375] Replica received explicit 
 promise request for position 0 with proposal 2
 I0909 22:46:59.267755 21897 leveldb.cpp:343] Persisting action (8 bytes) to 
 leveldb took 8.109338ms
 I0909 22:46:59.267916 21897 replica.cpp:676] Persisted action at 0
 I0909 22:46:59.270128 21902 replica.cpp:508] Replica received write request 
 for position 0
 I0909 22:46:59.270294 21902 leveldb.cpp:438] Reading position from leveldb 
 took 27443ns
 I0909 22:46:59.277220 21902 leveldb.cpp:343] Persisting action (14 bytes) to 
 leveldb took 6.801267ms
 I0909 22:46:59.277369 21902 replica.cpp:676] Persisted action at 0

[jira] [Assigned] (MESOS-1783) MasterTest.LaunchDuplicateOfferTest is flaky

2014-09-12 Thread Niklas Quarfot Nielsen (JIRA)


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

Niklas Quarfot Nielsen reassigned MESOS-1783:
-

Assignee: Niklas Quarfot Nielsen

 MasterTest.LaunchDuplicateOfferTest is flaky
 

 Key: MESOS-1783
 URL: https://issues.apache.org/jira/browse/MESOS-1783
 Project: Mesos
  Issue Type: Bug
  Components: test
Affects Versions: 0.20.0
 Environment: ubuntu-14.04-gcc Jenkins VM
Reporter: Yan Xu
Assignee: Niklas Quarfot Nielsen

 {noformat:title=}
 [ RUN  ] MasterTest.LaunchDuplicateOfferTest
 Using temporary directory '/tmp/MasterTest_LaunchDuplicateOfferTest_3ifzmg'
 I0909 22:46:59.212977 21883 leveldb.cpp:176] Opened db in 20.307533ms
 I0909 22:46:59.219717 21883 leveldb.cpp:183] Compacted db in 6.470397ms
 I0909 22:46:59.219925 21883 leveldb.cpp:198] Created db iterator in 5571ns
 I0909 22:46:59.220100 21883 leveldb.cpp:204] Seeked to beginning of db in 
 1365ns
 I0909 22:46:59.220268 21883 leveldb.cpp:273] Iterated through 0 keys in the 
 db in 658ns
 I0909 22:46:59.220448 21883 replica.cpp:741] Replica recovered with log 
 positions 0 - 0 with 1 holes and 0 unlearned
 I0909 22:46:59.220855 21903 recover.cpp:425] Starting replica recovery
 I0909 22:46:59.221103 21903 recover.cpp:451] Replica is in EMPTY status
 I0909 22:46:59.221626 21903 replica.cpp:638] Replica in EMPTY status received 
 a broadcasted recover request
 I0909 22:46:59.221914 21903 recover.cpp:188] Received a recover response from 
 a replica in EMPTY status
 I0909 22:46:59.04 21903 recover.cpp:542] Updating replica status to 
 STARTING
 I0909 22:46:59.232590 21900 master.cpp:286] Master 
 20140909-224659-16842879-44263-21883 (trusty) started on 127.0.1.1:44263
 I0909 22:46:59.233278 21900 master.cpp:332] Master only allowing 
 authenticated frameworks to register
 I0909 22:46:59.233543 21900 master.cpp:337] Master only allowing 
 authenticated slaves to register
 I0909 22:46:59.233934 21900 credentials.hpp:36] Loading credentials for 
 authentication from 
 '/tmp/MasterTest_LaunchDuplicateOfferTest_3ifzmg/credentials'
 I0909 22:46:59.236431 21900 master.cpp:366] Authorization enabled
 I0909 22:46:59.237522 21898 hierarchical_allocator_process.hpp:299] 
 Initializing hierarchical allocator process with master : 
 master@127.0.1.1:44263
 I0909 22:46:59.237877 21904 master.cpp:120] No whitelist given. Advertising 
 offers for all slaves
 I0909 22:46:59.238723 21903 leveldb.cpp:306] Persisting metadata (8 bytes) to 
 leveldb took 16.245391ms
 I0909 22:46:59.238916 21903 replica.cpp:320] Persisted replica status to 
 STARTING
 I0909 22:46:59.239203 21903 recover.cpp:451] Replica is in STARTING status
 I0909 22:46:59.239724 21903 replica.cpp:638] Replica in STARTING status 
 received a broadcasted recover request
 I0909 22:46:59.239967 21903 recover.cpp:188] Received a recover response from 
 a replica in STARTING status
 I0909 22:46:59.240304 21903 recover.cpp:542] Updating replica status to VOTING
 I0909 22:46:59.240684 21900 master.cpp:1212] The newly elected leader is 
 master@127.0.1.1:44263 with id 20140909-224659-16842879-44263-21883
 I0909 22:46:59.240846 21900 master.cpp:1225] Elected as the leading master!
 I0909 22:46:59.241149 21900 master.cpp:1043] Recovering from registrar
 I0909 22:46:59.241509 21898 registrar.cpp:313] Recovering registrar
 I0909 22:46:59.248440 21903 leveldb.cpp:306] Persisting metadata (8 bytes) to 
 leveldb took 7.864221ms
 I0909 22:46:59.248644 21903 replica.cpp:320] Persisted replica status to 
 VOTING
 I0909 22:46:59.248846 21903 recover.cpp:556] Successfully joined the Paxos 
 group
 I0909 22:46:59.249330 21897 log.cpp:656] Attempting to start the writer
 I0909 22:46:59.249809 21897 replica.cpp:474] Replica received implicit 
 promise request with proposal 1
 I0909 22:46:59.250075 21903 recover.cpp:440] Recover process terminated
 I0909 22:46:59.258286 21897 leveldb.cpp:306] Persisting metadata (8 bytes) to 
 leveldb took 8.292514ms
 I0909 22:46:59.258489 21897 replica.cpp:342] Persisted promised to 1
 I0909 22:46:59.258848 21897 coordinator.cpp:230] Coordinator attemping to 
 fill missing position
 I0909 22:46:59.259454 21897 replica.cpp:375] Replica received explicit 
 promise request for position 0 with proposal 2
 I0909 22:46:59.267755 21897 leveldb.cpp:343] Persisting action (8 bytes) to 
 leveldb took 8.109338ms
 I0909 22:46:59.267916 21897 replica.cpp:676] Persisted action at 0
 I0909 22:46:59.270128 21902 replica.cpp:508] Replica received write request 
 for position 0
 I0909 22:46:59.270294 21902 leveldb.cpp:438] Reading position from leveldb 
 took 27443ns
 I0909 22:46:59.277220 21902 leveldb.cpp:343] Persisting action (14 bytes) to 
 leveldb took 6.801267ms
 I0909 22:46:59.277369 21902 replica.cpp:676] Persisted action at 0

[jira] [Commented] (MESOS-1761) docker containerizer should override entrypoint when starting executor.

2014-09-12 Thread Jay Buffington (JIRA)

[
https://issues.apache.org/jira/browse/MESOS-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131836#comment-14131836
]

Jay Buffington commented on MESOS-1761:
---

If you specify CommandInfo with an image that has an entrypoint, the
CommandInfo.value will be appended to the entrypoint value unless you use
--entrypoint. Example:

docker image has ENTRYPOINT ls set.
scheduler passes CommandInfo.value set to echo hello world
docker containerizer will run ls echo hello world

I argue there is no valid use case for using the image's entrypoint when
CommandInfo is specified.

That said, MESOS-1770 should address the issue I'm seeing.

docker containerizer should override entrypoint when starting executor.
---

Key: MESOS-1761
URL: https://issues.apache.org/jira/browse/MESOS-1761
Project: Mesos
Issue Type: Bug
Components: containerization
Reporter: Jay Buffington
Assignee: Timothy Chen
Labels: docker

When I specify an ExecutorInfo with a ContainerInfo set, the docker
containerizer will do {{docker run ... /bin/sh -c ./my-executor}}.
If the docker image the user specifies has an entrypoint configured the
executor command will be appended to the entrypoint rather than overwriting
it. The docker docs says:
{quote}
Unlike the behavior of the CMD instruction, The ENTRYPOINT instruction adds
an entry command that will not be overwritten when arguments are passed to
docker run. This allows arguments to be passed to the entry point, i.e.
docker run image -d will pass the -d argument to the entry point.
{quote}
This results in docker running the entrypoint inside the container with the
executorinfo's command as an argument. If you specified an executor this is
never what you want.
I suggest docker run use {{--entrypoint}} when starting an executor inside
the container.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-750) Require compilers that support c++11


[ 
https://issues.apache.org/jira/browse/MESOS-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131954#comment-14131954
 ] 

Dominic Hamon commented on MESOS-750:
-

I wasn't planning on it to avoid churn in the documentation. Having the 
configure script (and to a lesser extent, CI coverage) be the source of truth 
is more stable.

If you think it's worthwhile, we can certainly try to track the supported 
compiler versions.

 Require compilers that support c++11
 

 Key: MESOS-750
 URL: https://issues.apache.org/jira/browse/MESOS-750
 Project: Mesos
  Issue Type: Improvement
  Components: technical debt
Reporter: Benjamin Mahler
Assignee: Dominic Hamon
 Fix For: 0.21.0


 Requiring C++11 support will provide substantial benefits to Mesos.
 Most notably, the lack of lambda support has resulted in a proliferation of 
 continuation style functions scattered throughout the code. Having lambdas 
 will allow us to reduce this clutter and simplify the code.
 This will require carefully documenting how to get Mesos compiling on various 
 systems to make this transition easy.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-1776) --without-PACKAGE will set incorrect dependency prefix


[ 
https://issues.apache.org/jira/browse/MESOS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131987#comment-14131987
 ] 

Kamil Domański commented on MESOS-1776:
---

As it turns out, {{\-\-without-package}} cannot be disabled because it is a 
canonical style handled by autoconf itself and not by the script. I will 
instead make {{\-\-without-package}} behave just like {{\-\-with-package=}}

 --without-PACKAGE will set incorrect dependency prefix
 --

 Key: MESOS-1776
 URL: https://issues.apache.org/jira/browse/MESOS-1776
 Project: Mesos
  Issue Type: Bug
  Components: build
Affects Versions: 0.20.0
Reporter: Kamil Domański
Assignee: Kamil Domański
  Labels: build

 When disabling a particular bundled dependency with *--without-PACKAGE*, the 
 build scripts of both Mesos and libprocess will set a corresponding variable 
 to no. This is later treated as prefix under which to search for the 
 package.
 For example, with *--without-protobuf*, the script will search for *protoc* 
 under *no/bin* and obviously fail. I would propose to get rid of these 
 prefixes entirely and instead search in default locations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MESOS-750) Require compilers that support c++11

2014-09-12 Thread Cody Maloney (JIRA)


[ 
https://issues.apache.org/jira/browse/MESOS-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131985#comment-14131985
 ] 

Cody Maloney edited comment on MESOS-750 at 9/12/14 7:46 PM:
-

There hasn't really been a discussion of how frequently we want to bump... (It 
would be nice to drop 4.4 and get to 47 preferrably, 4.6 if needed since those 
add a lot of functionality, but there is a user requiring 4.4 at the moment).

I'm planning to look into getting at least a private 4.4 slave for now, and it 
should be possible to get 4.4 on the apache reviewbot (Someone who can work on 
those should be able to request it be installed then update the config).

The legacy thing there is actually something that would effect newer compilers 
as well (C++ has no defined static initialization order between compiled 
modules), it is just a very intermittent problem (Using extern makes the 
compiler reconcile that somewhat). Really we want constexpr C++11 there (Or a 
function which returns the value. statics within function bodies have well 
defined initialization order) :P


was (Author: cmaloney):
There hasn't really been a discussion of how frequently we want to bump... (It 
would be nice to drop 4.4 and get to 47 preferrably, 4.6 if needed since those 
add a lot of functionality, but there is a user requiring 4.4 at the moment).

I'm planning to look into getting at least a private 4.4 slave for now, and it 
should be possible to get 4.4 on the apache reviewbot (Someone who can work on 
those should be able to request it be installed then update the config).

The legacy thing there is actually something that would effect newer compilers 
as well (C++ has no defined static initialization order between compiled 
modules), it is just a very intermittent problem (Using extern makes the 
compiler reconcile that somewhat). Really we want constexpr C++11 there :P

 Require compilers that support c++11
 

 Key: MESOS-750
 URL: https://issues.apache.org/jira/browse/MESOS-750
 Project: Mesos
  Issue Type: Improvement
  Components: technical debt
Reporter: Benjamin Mahler
Assignee: Dominic Hamon
 Fix For: 0.21.0


 Requiring C++11 support will provide substantial benefits to Mesos.
 Most notably, the lack of lambda support has resulted in a proliferation of 
 continuation style functions scattered throughout the code. Having lambdas 
 will allow us to reduce this clutter and simplify the code.
 This will require carefully documenting how to get Mesos compiling on various 
 systems to make this transition easy.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (MESOS-1776) --without-PACKAGE will set incorrect dependency prefix


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

Kamil Domański updated MESOS-1776:
--
Comment: was deleted

(was: As it turns out, {{\-\-without-package}} cannot be disabled because it is 
a canonical style handled by autoconf itself and not by the script. I will 
instead make {{\-\-without-package}} behave just like {{\-\-with-package=}})

 --without-PACKAGE will set incorrect dependency prefix
 --

 Key: MESOS-1776
 URL: https://issues.apache.org/jira/browse/MESOS-1776
 Project: Mesos
  Issue Type: Bug
  Components: build
Affects Versions: 0.20.0
Reporter: Kamil Domański
Assignee: Kamil Domański
  Labels: build

 When disabling a particular bundled dependency with *--without-PACKAGE*, the 
 build scripts of both Mesos and libprocess will set a corresponding variable 
 to no. This is later treated as prefix under which to search for the 
 package.
 For example, with *--without-protobuf*, the script will search for *protoc* 
 under *no/bin* and obviously fail. I would propose to get rid of these 
 prefixes entirely and instead search in default locations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MESOS-1788) Add c++11 feature whitelist to style guide

Dominic Hamon created MESOS-1788:


 Summary: Add c++11 feature whitelist to style guide
 Key: MESOS-1788
 URL: https://issues.apache.org/jira/browse/MESOS-1788
 Project: Mesos
  Issue Type: Documentation
  Components: documentation
Reporter: Dominic Hamon
Priority: Minor


We now support a subset of C++11 as checked by the {{configure}} script. It 
would be useful to have documentation in the style guide regarding the white 
list.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-750) Require compilers that support c++11


[ 
https://issues.apache.org/jira/browse/MESOS-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14132077#comment-14132077
 ] 

Dominic Hamon commented on MESOS-750:
-

[~bmahler] That's a good point. We probably need to have a documented whitelist 
in the style guide for the features that we have enabled (MESOS-1788).

[~cmaloney] If I had my way, we'd jump straight to 4.8.2 at this point as it's 
widely available. I am curious if the user stuck on 4.4 actually needs to build 
from head or if they can run from the distributed binaries. Perhaps there are 
some glibc incompatibilities?

 Require compilers that support c++11
 

 Key: MESOS-750
 URL: https://issues.apache.org/jira/browse/MESOS-750
 Project: Mesos
  Issue Type: Improvement
  Components: technical debt
Reporter: Benjamin Mahler
Assignee: Dominic Hamon
 Fix For: 0.21.0


 Requiring C++11 support will provide substantial benefits to Mesos.
 Most notably, the lack of lambda support has resulted in a proliferation of 
 continuation style functions scattered throughout the code. Having lambdas 
 will allow us to reduce this clutter and simplify the code.
 This will require carefully documenting how to get Mesos compiling on various 
 systems to make this transition easy.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-750) Require compilers that support c++11

2014-09-12 Thread Cody Maloney (JIRA)

[
https://issues.apache.org/jira/browse/MESOS-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14132094#comment-14132094
]

Cody Maloney commented on MESOS-750:

[~dhamon] The thing with jumping straight to 4.8.2 is what distributions do we
want to have work with mesos out of the box. We should really define what we
want as compatible platforms (The last redhat/CentOs release? All supported
ubuntu releases? etc). Whatever the default compilers are on those
distributions are what we should support. Note that if 4.8 is the baseline, we
will probably want to be explicit about not accepting 4.8.0, 4.8.1 (They had
some very major bugs).

I personally prefer just requiring people use a new compiler and making it easy
to get the blessed compiler version on older platforms (GCC 4.8 or 4.9. GCC
isn't that hard to build, nor does it take too long if you disable everything
but C/C++). But this should all probably be a seperate discussion thread.

As for the 4.4 user, that is actively being discussed / worked on.

Require compilers that support c++11

Key: MESOS-750
URL: https://issues.apache.org/jira/browse/MESOS-750
Project: Mesos
Issue Type: Improvement
Components: technical debt
Reporter: Benjamin Mahler
Assignee: Dominic Hamon
Fix For: 0.21.0

Requiring C++11 support will provide substantial benefits to Mesos.
Most notably, the lack of lambda support has resulted in a proliferation of
continuation style functions scattered throughout the code. Having lambdas
will allow us to reduce this clutter and simplify the code.
This will require carefully documenting how to get Mesos compiling on various
systems to make this transition easy.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-1621) Docker run networking should be configurable and support bridge network