[jira] [Created] (MESOS-7762) net::IP::Network not building on Windows

2017-07-05 Thread Andrew Schwartzmeyer (JIRA) 
Andrew Schwartzmeyer created MESOS-7762:
---

 Summary: net::IP::Network not building on Windows
 Key: MESOS-7762
 URL: https://issues.apache.org/jira/browse/MESOS-7762
 Project: Mesos
  Issue Type: Bug
  Components: stout
 Environment: Windows 10
Reporter: Andrew Schwartzmeyer
Assignee: Avinash Sridharan


Building master (well, 2c1be9ced) is currently broken on Windows. Repro:

{noformat}
git checkout 2c1be9ced 
mkdir build
cd build 
cmake .. -DENABLE_LIBEVENT=1 -DHAS_AUTHENTICATION=0 -G "Visual Studio 15 2017 
Win64" -T "host=x64"
cmake --build . --target stout-tests
{noformat}

(Build instructions here: 
https://github.com/apache/mesos/blob/master/docs/windows.md)

Get a bunch of compilation errors:

{noformat}
"C:\Users\andschwa\src\mesos-copy2\build\3rdparty\stout\tests\stout-tests.vcxproj"
 (default target) (1) ->
(ClCompile target) ->
  
C:\Users\andschwa\src\mesos-copy2\3rdparty\stout\include\stout/windows/ip.hpp(31):
 error C2065: 'IPNetwork': undeclared identifier (compiling source file 
C:\Users\andschwa\src\mesos-copy2\3rdparty\stout\tests\ip_tests.cpp) 
[C:\Users\ands
chwa\src\mesos-copy2\build\3rdparty\stout\tests\stout-tests.vcxproj]
  
C:\Users\andschwa\src\mesos-copy2\3rdparty\stout\include\stout/windows/ip.hpp(31):
 error C2923: 'Result': 'IPNetwork' is not a valid template type argument for 
parameter 'T' (compiling source file C:\Users\andschwa\src\mesos-copy2\3rdpar
ty\stout\tests\ip_tests.cpp) 
[C:\Users\andschwa\src\mesos-copy2\build\3rdparty\stout\tests\stout-tests.vcxproj]
  
C:\Users\andschwa\src\mesos-copy2\3rdparty\stout\include\stout/windows/ip.hpp(31):
 error C2653: 'IPNetwork': is not a class or namespace name (compiling source 
file C:\Users\andschwa\src\mesos-copy2\3rdparty\stout\tests\ip_tests.cpp) [C:
\Users\andschwa\src\mesos-copy2\build\3rdparty\stout\tests\stout-tests.vcxproj]
  
C:\Users\andschwa\src\mesos-copy2\3rdparty\stout\include\stout/windows/ip.hpp(34):
 error C2079: 'net::fromLinkDevice' uses undefined class 'Result' (compiling 
source file C:\Users\andschwa\src\mesos-copy2\3rdparty\stout\tests\ip_tests.cp
p) 
[C:\Users\andschwa\src\mesos-copy2\build\3rdparty\stout\tests\stout-tests.vcxproj]
  
C:\Users\andschwa\src\mesos-copy2\3rdparty\stout\include\stout/windows/ip.hpp(41):
 error C2440: 'return': cannot convert from 'Error' to 'Result' (compiling 
source file C:\Users\andschwa\src\mesos-copy2\3rdparty\stout\tests\ip_tests.cpp)
 
[C:\Users\andschwa\src\mesos-copy2\build\3rdparty\stout\tests\stout-tests.vcxproj]
  
C:\Users\andschwa\src\mesos-copy2\3rdparty\stout\include\stout/windows/ip.hpp(49):
 error C2440: 'return': cannot convert from 'WindowsError' to 'Result' 
(compiling source file 
C:\Users\andschwa\src\mesos-copy2\3rdparty\stout\tests\ip_tes
ts.cpp) 
[C:\Users\andschwa\src\mesos-copy2\build\3rdparty\stout\tests\stout-tests.vcxproj]
  
C:\Users\andschwa\src\mesos-copy2\3rdparty\stout\include\stout/windows/ip.hpp(58):
 error C2440: 'return': cannot convert from 'WindowsError' to 'Result' 
(compiling source file 
C:\Users\andschwa\src\mesos-copy2\3rdparty\stout\tests\ip_tes
ts.cpp) 
[C:\Users\andschwa\src\mesos-copy2\build\3rdparty\stout\tests\stout-tests.vcxproj]
  
C:\Users\andschwa\src\mesos-copy2\3rdparty\stout\include\stout/windows/ip.hpp(70):
 error C2065: 'IPNetwork': undeclared identifier (compiling source file 
C:\Users\andschwa\src\mesos-copy2\3rdparty\stout\tests\ip_tests.cpp) 
[C:\Users\ands
chwa\src\mesos-copy2\build\3rdparty\stout\tests\stout-tests.vcxproj]
  
C:\Users\andschwa\src\mesos-copy2\3rdparty\stout\include\stout/windows/ip.hpp(70):
 error C2923: 'Try': 'IPNetwork' is not a valid template type argument for 
parameter 'T' (compiling source file C:\Users\andschwa\src\mesos-copy2\3rdparty\
stout\tests\ip_tests.cpp) 
[C:\Users\andschwa\src\mesos-copy2\build\3rdparty\stout\tests\stout-tests.vcxproj]
  
C:\Users\andschwa\src\mesos-copy2\3rdparty\stout\include\stout/windows/ip.hpp(70):
 error C2653: 'IPNetwork': is not a class or namespace name (compiling source 
file C:\Users\andschwa\src\mesos-copy2\3rdparty\stout\tests\ip_tests.cpp) [C:
\Users\andschwa\src\mesos-copy2\build\3rdparty\stout\tests\stout-tests.vcxproj]
  
C:\Users\andschwa\src\mesos-copy2\3rdparty\stout\include\stout/windows/ip.hpp(70):
 error C3861: 'create': identifier not found (compiling source file 
C:\Users\andschwa\src\mesos-copy2\3rdparty\stout\tests\ip_tests.cpp) 
[C:\Users\andschwa
\src\mesos-copy2\build\3rdparty\stout\tests\stout-tests.vcxproj]
...
{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7761) Website ruby deps do not bundle on macOS

2017-07-05 Thread Vinod Kone (JIRA) 

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

Vinod Kone updated MESOS-7761:
--
Shepherd: Vinod Kone
  Sprint: Mesosphere Sprint 58

> Website ruby deps do not bundle on macOS
> 
>
> Key: MESOS-7761
> URL: https://issues.apache.org/jira/browse/MESOS-7761
> Project: Mesos
>  Issue Type: Bug
>  Components: project website
>Reporter: Benjamin Bannier
>Assignee: Benjamin Bannier
>  Labels: mesosphere
>
> When trying to bundle the ruby dependencies of the website on macOS-10.12.5 I 
> get
> {code}
> $ cd site/
> $ bundle install
> Fetching gem metadata from https://rubygems.org/
> Fetching version metadata from https://rubygems.org/..
> Fetching dependency metadata from https://rubygems.org/.
> Using coffee-script-source 1.6.3
> Using multi_json 1.8.2
> Using chunky_png 1.2.9
> Using fssm 0.2.10
> Using sass 3.2.12
> Using tilt 1.3.7
> Using kramdown 1.2.0
> Using i18n 0.6.5
> Using rb-fsevent 0.9.3
> Using ffi 1.9.3
> Using rack 1.5.2
> Using thor 0.18.1
> Using bundler 1.15.1
> Using hike 1.2.3
> Fetching eventmachine 1.0.3
> Installing eventmachine 1.0.3 with native extensions
> Using http_parser.rb 0.5.3
> Using addressable 2.3.5
> Using atomic 1.1.14
> Using rdiscount 2.1.7
> Using htmlentities 4.3.2
> Fetching libv8 3.16.14.15
> Installing libv8 3.16.14.15 with native extensions
> Using ref 2.0.0
> Using execjs 1.4.0
> Using compass 0.12.2
> Using haml 4.0.4
> Using activesupport 3.2.15
> Using rb-inotify 0.9.2
> Using rb-kqueue 0.2.0
> Using rack-test 0.6.2
> Using rack-livereload 0.3.15
> Using rouge 0.3.10
> Using sprockets 2.10.0
> Gem::Ext::BuildError: ERROR: Failed to build gem native extension.
> current directory: 
> /Users/bbannier/src/mesos/site/vendor/ruby/2.4.0/gems/eventmachine-1.0.3/ext
> /Users/bbannier/src/homebrew/opt/ruby/bin/ruby -r 
> ./siteconf20170705-46478-cy91ue.rb extconf.rb
> checking for rb_trap_immediate in ruby.h,rubysig.h... no
> checking for rb_thread_blocking_region()... no
> checking for inotify_init() in sys/inotify.h... no
> checking for __NR_inotify_init in sys/syscall.h... no
> checking for writev() in sys/uio.h... yes
> checking for rb_wait_for_single_fd()... yes
> checking for rb_enable_interrupt()... no
> checking for rb_time_new()... yes
> checking for sys/event.h... yes
> checking for sys/queue.h... yes
> creating Makefile
> current directory: 
> /Users/bbannier/src/mesos/site/vendor/ruby/2.4.0/gems/eventmachine-1.0.3/ext
> make "DESTDIR=" clean
> current directory: 
> /Users/bbannier/src/mesos/site/vendor/ruby/2.4.0/gems/eventmachine-1.0.3/ext
> make "DESTDIR="
> compiling binder.cpp
> compiling cmain.cpp
> compiling ed.cpp
> compiling em.cpp
> compiling kb.cpp
> compiling page.cpp
> compiling pipe.cpp
> compiling rubymain.cpp
> compiling ssl.cpp
> In file included from pipe.cpp:20:
> In file included from ./project.h:149:
> ./binder.h:35:3: warning: 'const' type qualifier on return type has no effect 
> [-Wignored-qualifiers]
> const unsigned long GetBinding() {return Binding;}
> ^~
> In file included from page.cpp:21:
> In file included from ./project.h:149:
> ./binder.h:35:3: warning: 'const' type qualifier on return type has no effect 
> [-Wignored-qualifiers]
> const unsigned long GetBinding() {return Binding;}
> ^~
> In file included from kb.cpp:20:
> In file included from ./project.h:149:
> ./binder.h:35:3: warning: 'const' type qualifier on return type has no effect 
> [-Wignored-qualifiers]
> const unsigned long GetBinding() {return Binding;}
> ^~
> In file included from em.cpp:23:
> In file included from ./project.h:149:
> ./binder.h:35:3: warning: 'const' type qualifier on return type has no effect 
> [-Wignored-qualifiers]
> const unsigned long GetBinding() {return Binding;}
> ^~
> In file included from binder.cpp:20:
> In file included from ./project.h:149:
> ./binder.h:35:3: warning: 'const' type qualifier on return type has no effect 
> [-Wignored-qualifiers]
> const unsigned long GetBinding() {return Binding;}
> ^~
> In file included from rubymain.cpp:20:
> In file included from ./project.h:149:
> ./binder.h:35:3: warning: 'const' type qualifier on return type has no effect 
> [-Wignored-qualifiers]
> const unsigned long GetBinding() {return Binding;}
> ^~
> In file included from ed.cpp:20:
> In file included from ./project.h:149:
> ./binder.h:35:3: warning: 'const' type qualifier on return type has no effect 
> [-Wignored-qualifiers]
> const unsigned long GetBinding() {return Binding;}
> ^~
> In file included from cmain.cpp:20:
> In

[jira] [Assigned] (MESOS-7751) Mesos failed to build on Windows due to error C2039: 'parse': is not a member of 'mesos::internal::protobuf'

2017-07-05 Thread Joseph Wu (JIRA) 

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

Joseph Wu reassigned MESOS-7751:


   Resolution: Fixed
 Assignee: Jan Schlicht
Fix Version/s: 1.4.0

Fixed in review: https://reviews.apache.org/r/60653/

> Mesos failed to build on Windows due to error C2039: 'parse': is not a member 
> of 'mesos::internal::protobuf'
> 
>
> Key: MESOS-7751
> URL: https://issues.apache.org/jira/browse/MESOS-7751
> Project: Mesos
>  Issue Type: Bug
>  Components: build
> Environment: Windows Server 2012 R2 + VS2015 Update 3 + Mesos master 
> branch latest source
>Reporter: Karen Huang
>Assignee: Jan Schlicht
> Fix For: 1.4.0
>
>
> I try to build mesos with Debug|x64 configuration on Windows. It failed to 
> build due error C2039: 'parse': is not a member of 
> 'mesos::internal::protobuf'. This issue can be reproduced from master branch 
> revision 15078ad 
> [15078ad|https://github.com/apache/mesos/commit/15078adddec1a2fca80978eb29b6889eb15db4b1#diff-6141d9940e12f6e495954cacbe037016].
>  Could you please take a look at this? Thanks in advance!
> Here is repro steps:
>  1. git clone -c core.autocrlf=true https://github.com/apache/mesos 
> D:\mesos\src
>  2. Open a VS amd64 command prompt as admin and browse to D:\mesos\src
>  3. bootstrap.bat
>  4. mkdir build_x64 && pushd build_x64
>  5. cmake ..\src -G "Visual Studio 14 2015 Win64" 
> -DCMAKE_SYSTEM_VERSION=10.0.14393.0 -DENABLE_LIBEVENT=1 
> -DHAS_AUTHENTICATION=0 -DPATCHEXE_PATH=$quotC:\gnuwin32\bin$quot -T host=x64 
> 6. msbuild Mesos.sln /p:Configuration=Debug /p:Platform=x64 /m /t:Rebuild
> Acutal result:
> "D:\Mesos\build_x64\Mesos.sln" (Rebuild target) (1) ->
>"D:\Mesos\build_x64\src\mesos-1.4.0.vcxproj.metaproj" (Rebuild target) 
> (16) ->
>"D:\Mesos\build_x64\src\mesos-1.4.0.vcxproj" (Rebuild target) (57) ->
>(ClCompile target) -> 
>  D:\Mesos\src\src\resource_provider\daemon.cpp(130): error C2039: 
> 'parse': is not a member of 'mesos::internal::protobuf' 
> [D:\Mesos\build_x64\src\mesos-1.4.0.vcxproj]
>  D:\Mesos\src\src\resource_provider\daemon.cpp(130): error C2065: 
> 'parse': undeclared identifier [D:\Mesos\build_x64\src\mesos-1.4.0.vcxproj]
>  D:\Mesos\src\src\resource_provider\daemon.cpp(130): error C2275: 
> 'mesos::ResourceProviderInfo': illegal use of this type as an expression 
> [D:\Mesos\build_x64\src\mesos-1.4.0.vcxproj]
>  D:\Mesos\src\src\resource_provider\daemon.cpp(129): error C2512: 
> 'Try': no appropriate default constructor 
> available [D:\Mesos\build_x64\src\mesos-1.4.0.vcxproj]
> 387 Warning(s)
> 4 Error(s)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-5675) Add support for master capabilities

2017-07-05 Thread Tomasz Janiszewski (JIRA) 

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

Tomasz Janiszewski commented on MESOS-5675:
---

https://lists.apache.org/thread.html/22ec645c835552e7c6b03ffb61368f814765c8a701d4736efa4eb205@%3Cuser.mesos.apache.org%3E

> Add support for master capabilities
> ---
>
> Key: MESOS-5675
> URL: https://issues.apache.org/jira/browse/MESOS-5675
> Project: Mesos
>  Issue Type: Improvement
>  Components: master
>Reporter: Neil Conway
>  Labels: mesosphere
>
> Right now, frameworks can advertise their capabilities to the master via the 
> {{FrameworkInfo}} they use for registration/re-registration. This allows 
> masters to provide backward compatibility for old frameworks that don't 
> support new functionality.
> To allow new frameworks to support backward compatibility with old masters, 
> the inverse concept would be useful: masters would tell frameworks which 
> capabilities are supported by the master, which the frameworks could then use 
> to decide whether to use features only supported by more recent versions of 
> the master.
> For now, frameworks can workaround this by looking at the master's version 
> number, but that seems a bit fragile and hacky.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7292) Introduce a "sensitive mode" in Mesos which prevents leaks of sensitive data.

2017-07-05 Thread Martin Tapp (JIRA) 

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

Martin Tapp commented on MESOS-7292:


Please make the POSSIBLY-SENSITIVE-DATA optional as noted in the code as we 
can't identify anonymous tasks using ENV vars 
(https://github.com/apache/mesos/blob/master/src/launcher/executor.cpp#L470).
Thanks

> Introduce a "sensitive mode" in Mesos which prevents leaks of sensitive data.
> -
>
> Key: MESOS-7292
> URL: https://issues.apache.org/jira/browse/MESOS-7292
> Project: Mesos
>  Issue Type: Improvement
>  Components: security
>Reporter: Alexander Rukletsov
>  Labels: mesosphere, security
>
> Consider a following scenario. A user passes some sensitive data in an 
> environment variable to a task. These data may be logged by Mesos components, 
> e.g., executor as part of {{mesos-containerizer}} invocation. While this is 
> useful for debugging, this might be an issue in some production environments.
> One of the solution is to have global "sensitive mode", that turns off 
> logging of such sensitive data.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MESOS-7761) Website ruby deps do not bundle on macOS

2017-07-05 Thread Benjamin Bannier (JIRA) 
Benjamin Bannier created MESOS-7761:
---

 Summary: Website ruby deps do not bundle on macOS
 Key: MESOS-7761
 URL: https://issues.apache.org/jira/browse/MESOS-7761
 Project: Mesos
  Issue Type: Bug
  Components: project website
Reporter: Benjamin Bannier


When trying to bundle the ruby dependencies of the website on macOS-10.12.5 I 
get

{code}
$ cd site/
$ bundle install
Fetching gem metadata from https://rubygems.org/
Fetching version metadata from https://rubygems.org/..
Fetching dependency metadata from https://rubygems.org/.
Using coffee-script-source 1.6.3
Using multi_json 1.8.2
Using chunky_png 1.2.9
Using fssm 0.2.10
Using sass 3.2.12
Using tilt 1.3.7
Using kramdown 1.2.0
Using i18n 0.6.5
Using rb-fsevent 0.9.3
Using ffi 1.9.3
Using rack 1.5.2
Using thor 0.18.1
Using bundler 1.15.1
Using hike 1.2.3
Fetching eventmachine 1.0.3
Installing eventmachine 1.0.3 with native extensions
Using http_parser.rb 0.5.3
Using addressable 2.3.5
Using atomic 1.1.14
Using rdiscount 2.1.7
Using htmlentities 4.3.2
Fetching libv8 3.16.14.15
Installing libv8 3.16.14.15 with native extensions
Using ref 2.0.0
Using execjs 1.4.0
Using compass 0.12.2
Using haml 4.0.4
Using activesupport 3.2.15
Using rb-inotify 0.9.2
Using rb-kqueue 0.2.0
Using rack-test 0.6.2
Using rack-livereload 0.3.15
Using rouge 0.3.10
Using sprockets 2.10.0
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

current directory: 
/Users/bbannier/src/mesos/site/vendor/ruby/2.4.0/gems/eventmachine-1.0.3/ext
/Users/bbannier/src/homebrew/opt/ruby/bin/ruby -r 
./siteconf20170705-46478-cy91ue.rb extconf.rb
checking for rb_trap_immediate in ruby.h,rubysig.h... no
checking for rb_thread_blocking_region()... no
checking for inotify_init() in sys/inotify.h... no
checking for __NR_inotify_init in sys/syscall.h... no
checking for writev() in sys/uio.h... yes
checking for rb_wait_for_single_fd()... yes
checking for rb_enable_interrupt()... no
checking for rb_time_new()... yes
checking for sys/event.h... yes
checking for sys/queue.h... yes
creating Makefile

current directory: 
/Users/bbannier/src/mesos/site/vendor/ruby/2.4.0/gems/eventmachine-1.0.3/ext
make "DESTDIR=" clean

current directory: 
/Users/bbannier/src/mesos/site/vendor/ruby/2.4.0/gems/eventmachine-1.0.3/ext
make "DESTDIR="
compiling binder.cpp
compiling cmain.cpp
compiling ed.cpp
compiling em.cpp
compiling kb.cpp
compiling page.cpp
compiling pipe.cpp
compiling rubymain.cpp
compiling ssl.cpp
In file included from pipe.cpp:20:
In file included from ./project.h:149:
./binder.h:35:3: warning: 'const' type qualifier on return type has no effect 
[-Wignored-qualifiers]
const unsigned long GetBinding() {return Binding;}
^~
In file included from page.cpp:21:
In file included from ./project.h:149:
./binder.h:35:3: warning: 'const' type qualifier on return type has no effect 
[-Wignored-qualifiers]
const unsigned long GetBinding() {return Binding;}
^~
In file included from kb.cpp:20:
In file included from ./project.h:149:
./binder.h:35:3: warning: 'const' type qualifier on return type has no effect 
[-Wignored-qualifiers]
const unsigned long GetBinding() {return Binding;}
^~
In file included from em.cpp:23:
In file included from ./project.h:149:
./binder.h:35:3: warning: 'const' type qualifier on return type has no effect 
[-Wignored-qualifiers]
const unsigned long GetBinding() {return Binding;}
^~
In file included from binder.cpp:20:
In file included from ./project.h:149:
./binder.h:35:3: warning: 'const' type qualifier on return type has no effect 
[-Wignored-qualifiers]
const unsigned long GetBinding() {return Binding;}
^~
In file included from rubymain.cpp:20:
In file included from ./project.h:149:
./binder.h:35:3: warning: 'const' type qualifier on return type has no effect 
[-Wignored-qualifiers]
const unsigned long GetBinding() {return Binding;}
^~
In file included from ed.cpp:20:
In file included from ./project.h:149:
./binder.h:35:3: warning: 'const' type qualifier on return type has no effect 
[-Wignored-qualifiers]
const unsigned long GetBinding() {return Binding;}
^~
In file included from cmain.cpp:20:
In file included from ./project.h:149:
./binder.h:35:3: warning: 'const' type qualifier on return type has no effect 
[-Wignored-qualifiers]
const unsigned long GetBinding() {return Binding;}
^~
In file included from ssl.cpp:23:
In file included from ./project.h:149:
./binder.h:35:3: warning: 'const' type qualifier on return type has no effect 
[-Wignored-qualifiers]
const unsigned long GetBinding() {return Binding;}
^~
In file

[jira] [Assigned] (MESOS-7761) Website ruby deps do not bundle on macOS

2017-07-05 Thread Benjamin Bannier (JIRA) 

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

Benjamin Bannier reassigned MESOS-7761:
---

Assignee: Benjamin Bannier

> Website ruby deps do not bundle on macOS
> 
>
> Key: MESOS-7761
> URL: https://issues.apache.org/jira/browse/MESOS-7761
> Project: Mesos
>  Issue Type: Bug
>  Components: project website
>Reporter: Benjamin Bannier
>Assignee: Benjamin Bannier
>  Labels: mesosphere
>
> When trying to bundle the ruby dependencies of the website on macOS-10.12.5 I 
> get
> {code}
> $ cd site/
> $ bundle install
> Fetching gem metadata from https://rubygems.org/
> Fetching version metadata from https://rubygems.org/..
> Fetching dependency metadata from https://rubygems.org/.
> Using coffee-script-source 1.6.3
> Using multi_json 1.8.2
> Using chunky_png 1.2.9
> Using fssm 0.2.10
> Using sass 3.2.12
> Using tilt 1.3.7
> Using kramdown 1.2.0
> Using i18n 0.6.5
> Using rb-fsevent 0.9.3
> Using ffi 1.9.3
> Using rack 1.5.2
> Using thor 0.18.1
> Using bundler 1.15.1
> Using hike 1.2.3
> Fetching eventmachine 1.0.3
> Installing eventmachine 1.0.3 with native extensions
> Using http_parser.rb 0.5.3
> Using addressable 2.3.5
> Using atomic 1.1.14
> Using rdiscount 2.1.7
> Using htmlentities 4.3.2
> Fetching libv8 3.16.14.15
> Installing libv8 3.16.14.15 with native extensions
> Using ref 2.0.0
> Using execjs 1.4.0
> Using compass 0.12.2
> Using haml 4.0.4
> Using activesupport 3.2.15
> Using rb-inotify 0.9.2
> Using rb-kqueue 0.2.0
> Using rack-test 0.6.2
> Using rack-livereload 0.3.15
> Using rouge 0.3.10
> Using sprockets 2.10.0
> Gem::Ext::BuildError: ERROR: Failed to build gem native extension.
> current directory: 
> /Users/bbannier/src/mesos/site/vendor/ruby/2.4.0/gems/eventmachine-1.0.3/ext
> /Users/bbannier/src/homebrew/opt/ruby/bin/ruby -r 
> ./siteconf20170705-46478-cy91ue.rb extconf.rb
> checking for rb_trap_immediate in ruby.h,rubysig.h... no
> checking for rb_thread_blocking_region()... no
> checking for inotify_init() in sys/inotify.h... no
> checking for __NR_inotify_init in sys/syscall.h... no
> checking for writev() in sys/uio.h... yes
> checking for rb_wait_for_single_fd()... yes
> checking for rb_enable_interrupt()... no
> checking for rb_time_new()... yes
> checking for sys/event.h... yes
> checking for sys/queue.h... yes
> creating Makefile
> current directory: 
> /Users/bbannier/src/mesos/site/vendor/ruby/2.4.0/gems/eventmachine-1.0.3/ext
> make "DESTDIR=" clean
> current directory: 
> /Users/bbannier/src/mesos/site/vendor/ruby/2.4.0/gems/eventmachine-1.0.3/ext
> make "DESTDIR="
> compiling binder.cpp
> compiling cmain.cpp
> compiling ed.cpp
> compiling em.cpp
> compiling kb.cpp
> compiling page.cpp
> compiling pipe.cpp
> compiling rubymain.cpp
> compiling ssl.cpp
> In file included from pipe.cpp:20:
> In file included from ./project.h:149:
> ./binder.h:35:3: warning: 'const' type qualifier on return type has no effect 
> [-Wignored-qualifiers]
> const unsigned long GetBinding() {return Binding;}
> ^~
> In file included from page.cpp:21:
> In file included from ./project.h:149:
> ./binder.h:35:3: warning: 'const' type qualifier on return type has no effect 
> [-Wignored-qualifiers]
> const unsigned long GetBinding() {return Binding;}
> ^~
> In file included from kb.cpp:20:
> In file included from ./project.h:149:
> ./binder.h:35:3: warning: 'const' type qualifier on return type has no effect 
> [-Wignored-qualifiers]
> const unsigned long GetBinding() {return Binding;}
> ^~
> In file included from em.cpp:23:
> In file included from ./project.h:149:
> ./binder.h:35:3: warning: 'const' type qualifier on return type has no effect 
> [-Wignored-qualifiers]
> const unsigned long GetBinding() {return Binding;}
> ^~
> In file included from binder.cpp:20:
> In file included from ./project.h:149:
> ./binder.h:35:3: warning: 'const' type qualifier on return type has no effect 
> [-Wignored-qualifiers]
> const unsigned long GetBinding() {return Binding;}
> ^~
> In file included from rubymain.cpp:20:
> In file included from ./project.h:149:
> ./binder.h:35:3: warning: 'const' type qualifier on return type has no effect 
> [-Wignored-qualifiers]
> const unsigned long GetBinding() {return Binding;}
> ^~
> In file included from ed.cpp:20:
> In file included from ./project.h:149:
> ./binder.h:35:3: warning: 'const' type qualifier on return type has no effect 
> [-Wignored-qualifiers]
> const unsigned long GetBinding() {return Binding;}
> ^~
> In file included from cmain.cpp:20:
> In file

[jira] [Commented] (MESOS-7735) The master crashes when state endpoint is hit during a task authorization.

2017-07-05 Thread Michael Park (JIRA) 

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

Michael Park commented on MESOS-7735:
-

{noformat}
commit e097f21124d16c80544af7aabc83bab5fb712453
Author: Michael Park 
Date:   Thu Jun 29 23:49:10 2017 -0700

Performed validation/normalization of `Resource`s before authorization.

Review: https://reviews.apache.org/r/60564
{noformat}
{noformat}
commit 63c8b1d63be363e96d7c2672d9d65b9d67ca48ed
Author: Michael Park 
Date:   Thu Jun 29 23:30:16 2017 -0700

Updated `validateAndNormalizeResources` to operate on `Operation`s.

Review: https://reviews.apache.org/r/60563
{noformat}
{noformat}
commit 710b72179938cac2100c90277ce7ced5c8ca3401
Author: Michael Park 
Date:   Thu Jun 29 20:53:59 2017 -0700

Updated `accept` to perform operation adjustment in one place.

It used to be that the minor adjustments that were made to operations
were done in various places across `accept` and `_accept`.

The "executor-injection" for LAUNCH_GROUP was at the beginning of
`accept`, "allocation-info-injection" for MULTI_ROLE was after offer
validation, and "health-check-injection" for LAUNCH was in `_accept`.

The `Master::accept` function is now broken down into distinct
"metrics accounting", "offer validation", "operation-adjustments", and
"authorization" stages.

Review: https://reviews.apache.org/r/60562
{noformat}

> The master crashes when state endpoint is hit during a task authorization.
> --
>
> Key: MESOS-7735
> URL: https://issues.apache.org/jira/browse/MESOS-7735
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Reporter: Michael Park
>Assignee: Michael Park
>Priority: Blocker
>
> With reservation refinement, the construction of {{Resources}} requires 
> {{Resource}} objects to have been validated and converted to the 
> "post-reservation-refinement" format. Generally speaking, validation and 
> conversion are the first steps we take with given {{Resource}} objects prior 
> to proceeding. In the master currently, we perform authorization first with 
> not-yet-validated, not-yet-converted {{Resource}} objects. During the 
> authorization phase, we add tasks with not-yet-validated, not-yet-converted 
> resources into {{framework->pendingTasks}} as well as 
> {{slave->pendingTasks}}. 
> (https://github.com/apache/mesos/blob/master/src/master/master.cpp#L3974-L3999).
>  If one hits the state endpoint on the master during this time, we get to 
> https://github.com/apache/mesos/blob/master/src/master/http.cpp#L278 which 
> tries to construct a {{Resources}} with {{taskInfo.resources()}} which is 
> not-yet-validated nor converted.
> I think the correct fix here is to perform validation / conversion prior to 
> authorization. The authorization code currently is written to carefully 
> inspect fields in both "pre-reservation-refinement" and 
> "post-reservation-refinement" formats. By performing validation / conversion 
> first, the authorization code would be simplified, and we're also much less 
> likely to make mistakes such as this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7735) The master crashes when state endpoint is hit during a task authorization.

2017-07-05 Thread Michael Park (JIRA) 

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

Michael Park commented on MESOS-7735:
-

{noformat}
commit fcc15438c6a4a6885ba31845f33dc07b6f766a62
Author: Michael Park mp...@apache.org
Date:   Thu Jun 29 17:57:43 2017 -0700

Replaced a few raw `for` loops with `foreach`.

Review: https://reviews.apache.org/r/60561
{noformat}

> The master crashes when state endpoint is hit during a task authorization.
> --
>
> Key: MESOS-7735
> URL: https://issues.apache.org/jira/browse/MESOS-7735
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Reporter: Michael Park
>Assignee: Michael Park
>Priority: Blocker
>
> With reservation refinement, the construction of {{Resources}} requires 
> {{Resource}} objects to have been validated and converted to the 
> "post-reservation-refinement" format. Generally speaking, validation and 
> conversion are the first steps we take with given {{Resource}} objects prior 
> to proceeding. In the master currently, we perform authorization first with 
> not-yet-validated, not-yet-converted {{Resource}} objects. During the 
> authorization phase, we add tasks with not-yet-validated, not-yet-converted 
> resources into {{framework->pendingTasks}} as well as 
> {{slave->pendingTasks}}. 
> (https://github.com/apache/mesos/blob/master/src/master/master.cpp#L3974-L3999).
>  If one hits the state endpoint on the master during this time, we get to 
> https://github.com/apache/mesos/blob/master/src/master/http.cpp#L278 which 
> tries to construct a {{Resources}} with {{taskInfo.resources()}} which is 
> not-yet-validated nor converted.
> I think the correct fix here is to perform validation / conversion prior to 
> authorization. The authorization code currently is written to carefully 
> inspect fields in both "pre-reservation-refinement" and 
> "post-reservation-refinement" formats. By performing validation / conversion 
> first, the authorization code would be simplified, and we're also much less 
> likely to make mistakes such as this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7760) An offer operation should be validated early in the master.

2017-07-05 Thread Michael Park (JIRA) 

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

Michael Park updated MESOS-7760:

Description: 
Currently, in the master code we incorrectly assume that an offer operation has
the correct sub-message that corresponds to the {{type}}. We should add this
validation step early in {{accept}} in order to give a better error message, and
also to allow the existing code to continue assume that the {{type}} indicates
the sub-message that will be set. We should also ensure that we have a known 
{{type}}.

  was:
Currently, in the master code we incorrectly assume that an offer operation has
the correct sub-message that corresponds to the {{type}}. We should add this
validation step early in {{accept}} in order to give a better error message, and
also to allow the existing code to continue assume that the {{type}} indicates
the sub-message that will be set.


> An offer operation should be validated early in the master.
> ---
>
> Key: MESOS-7760
> URL: https://issues.apache.org/jira/browse/MESOS-7760
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Reporter: Michael Park
>
> Currently, in the master code we incorrectly assume that an offer operation 
> has
> the correct sub-message that corresponds to the {{type}}. We should add this
> validation step early in {{accept}} in order to give a better error message, 
> and
> also to allow the existing code to continue assume that the {{type}} indicates
> the sub-message that will be set. We should also ensure that we have a known 
> {{type}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MESOS-7760) An offer operation should be validated.

2017-07-05 Thread Michael Park (JIRA) 
Michael Park created MESOS-7760:
---

 Summary: An offer operation should be validated.
 Key: MESOS-7760
 URL: https://issues.apache.org/jira/browse/MESOS-7760
 Project: Mesos
  Issue Type: Bug
  Components: master
Reporter: Michael Park


Currently, in the master code we incorrectly assume that an offer operation has
the correct sub-message that corresponds to the {{type}}. We should add this
validation step early in {{accept}} in order to give a better error message, and
also to allow the existing code to continue assume that the {{type}} indicates
the sub-message that will be set.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7760) An offer operation should be validated early in `accept`.

2017-07-05 Thread Michael Park (JIRA) 

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

Michael Park updated MESOS-7760:

Summary: An offer operation should be validated early in `accept`.  (was: 
An offer operation should be validated.)

> An offer operation should be validated early in `accept`.
> -
>
> Key: MESOS-7760
> URL: https://issues.apache.org/jira/browse/MESOS-7760
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Reporter: Michael Park
>
> Currently, in the master code we incorrectly assume that an offer operation 
> has
> the correct sub-message that corresponds to the {{type}}. We should add this
> validation step early in {{accept}} in order to give a better error message, 
> and
> also to allow the existing code to continue assume that the {{type}} indicates
> the sub-message that will be set.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (MESOS-7760) An offer operation should be validated early in the master.

2017-07-05 Thread Michael Park (JIRA) 

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

Michael Park updated MESOS-7760:

Summary: An offer operation should be validated early in the master.  (was: 
An offer operation should be validated early in `accept`.)

> An offer operation should be validated early in the master.
> ---
>
> Key: MESOS-7760
> URL: https://issues.apache.org/jira/browse/MESOS-7760
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Reporter: Michael Park
>
> Currently, in the master code we incorrectly assume that an offer operation 
> has
> the correct sub-message that corresponds to the {{type}}. We should add this
> validation step early in {{accept}} in order to give a better error message, 
> and
> also to allow the existing code to continue assume that the {{type}} indicates
> the sub-message that will be set.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7758) Stout doesn't build standalone.

2017-07-05 Thread Jan Schlicht (JIRA) 

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

Jan Schlicht commented on MESOS-7758:
-

Libprocess is affected as well.
{noformat}
$ cd build/3rdparty/libprocess
$ make
...
make[1]: *** No rule to make target `googlemock-build-stamp'.  Stop.
make: *** [../googletest-release-1.8.0/googlemock-build-stamp] Error 2
{noformat}


> Stout doesn't build standalone.
> ---
>
> Key: MESOS-7758
> URL: https://issues.apache.org/jira/browse/MESOS-7758
> Project: Mesos
>  Issue Type: Bug
>  Components: build, stout
>Reporter: James Peach
>
> Stout doesn't build in a standalone configuration:
> {noformat}
> $ cd ~/src/mesos/3rdparty/stout
> $ ./bootstrap
> $ cd ~/build/stout
> $ ~/src/mesos/3rdparty/stout/configure
> ...
> $ make
> ...
> make[1]: Leaving directory '/home/vagrant/build/stout/3rdparty'
> make[1]: Entering directory '/home/vagrant/build/stout/3rdparty'
> make[1]: *** No rule to make target 'googlemock-build-stamp'.  Stop.
> make[1]: Leaving directory '/home/vagrant/build/stout/3rdparty'
> make: *** [Makefile:1902: 
> 3rdparty/googletest-release-1.8.0/googlemock-build-stamp] Error 2
> {noformat}
> Note that the build expects 
> {{3rdparty/googletest-release-1.8.0/googlemock-build-stamp}}, but 
> {{googletest}} hasn't been staged yet:
> {noformat}
> [vagrant@fedora-26 stout]$ ls -l 3rdparty/
> total 44
> drwxr-xr-x.  3 vagrant vagrant  4096 Jan 18  2016 boost-1.53.0
> -rw-rw-r--.  1 vagrant vagrant 0 Jul  5 06:16 boost-1.53.0-stamp
> drwxrwxr-x.  8 vagrant vagrant  4096 Aug 15  2016 elfio-3.2
> -rw-rw-r--.  1 vagrant vagrant 0 Jul  5 06:16 elfio-3.2-stamp
> drwxr-xr-x. 10 vagrant vagrant  4096 Jul  5 06:16 glog-0.3.3
> -rw-rw-r--.  1 vagrant vagrant 0 Jul  5 06:16 glog-0.3.3-build-stamp
> -rw-rw-r--.  1 vagrant vagrant 0 Jul  5 06:16 glog-0.3.3-stamp
> -rw-rw-r--.  1 vagrant vagrant   734 Jul  5 06:03 gmock_sources.cc
> -rw-rw-r--.  1 vagrant vagrant 25657 Jul  5 06:03 Makefile
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MESOS-7759) Unbundled protobuf build doesn't work.

2017-07-05 Thread James Peach (JIRA) 
James Peach created MESOS-7759:
--

 Summary: Unbundled protobuf build doesn't work.
 Key: MESOS-7759
 URL: https://issues.apache.org/jira/browse/MESOS-7759
 Project: Mesos
  Issue Type: Bug
  Components: build
Reporter: James Peach


{noformat}
/opt/home/src/mesos/configure \
--prefix=/opt/mesos \
--disable-python \
--disable-java \
--enable-port-mapping-isolator \
--enable-silent-rules \
--with-protobuf=/usr \
CC=clang CXX=clang++
{noformat}

On Fedora 26, this results in the following configure error:
{noformat}
configure:22840: $? = 0
configure:22849: result: yes
configure:22955: checking google/protobuf/message.h usability
configure:22955: /usr/lib64/ccache/clang++ -c -O0 -g -Wno-unused-local-typedef 
-std=c++11 -isystem /usr/include/libnl3 -isystem /usr/include/apr-1 -isystem 
/usr/include/apr-1.0   -isystem /usr/include conftest.cpp >&5
In file included from conftest.cpp:70:
In file included from /usr/include/google/protobuf/message.h:114:
In file included from 
/usr/bin/../lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/string:52:
In file included from 
/usr/bin/../lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/bits/basic_string.h:6159:
In file included from 
/usr/bin/../lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/ext/string_conversions.h:41:
/usr/bin/../lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/cstdlib:75:15:
 fatal error: 'stdlib.h' file not found
#include_next 
  ^~
1 error generated.
{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MESOS-7758) Stout doesn't build standalone.

2017-07-05 Thread James Peach (JIRA) 

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

James Peach commented on MESOS-7758:


/cc [~nfnt]

> Stout doesn't build standalone.
> ---
>
> Key: MESOS-7758
> URL: https://issues.apache.org/jira/browse/MESOS-7758
> Project: Mesos
>  Issue Type: Bug
>  Components: build, stout
>Reporter: James Peach
>
> Stout doesn't build in a standalone configuration:
> {noformat}
> $ cd ~/src/mesos/3rdparty/stout
> $ ./bootstrap
> $ cd ~/build/stout
> $ ~/src/mesos/3rdparty/stout/configure
> ...
> $ make
> ...
> make[1]: Leaving directory '/home/vagrant/build/stout/3rdparty'
> make[1]: Entering directory '/home/vagrant/build/stout/3rdparty'
> make[1]: *** No rule to make target 'googlemock-build-stamp'.  Stop.
> make[1]: Leaving directory '/home/vagrant/build/stout/3rdparty'
> make: *** [Makefile:1902: 
> 3rdparty/googletest-release-1.8.0/googlemock-build-stamp] Error 2
> {noformat}
> Note that the build expects 
> {{3rdparty/googletest-release-1.8.0/googlemock-build-stamp}}, but 
> {{googletest}} hasn't been staged yet:
> {noformat}
> [vagrant@fedora-26 stout]$ ls -l 3rdparty/
> total 44
> drwxr-xr-x.  3 vagrant vagrant  4096 Jan 18  2016 boost-1.53.0
> -rw-rw-r--.  1 vagrant vagrant 0 Jul  5 06:16 boost-1.53.0-stamp
> drwxrwxr-x.  8 vagrant vagrant  4096 Aug 15  2016 elfio-3.2
> -rw-rw-r--.  1 vagrant vagrant 0 Jul  5 06:16 elfio-3.2-stamp
> drwxr-xr-x. 10 vagrant vagrant  4096 Jul  5 06:16 glog-0.3.3
> -rw-rw-r--.  1 vagrant vagrant 0 Jul  5 06:16 glog-0.3.3-build-stamp
> -rw-rw-r--.  1 vagrant vagrant 0 Jul  5 06:16 glog-0.3.3-stamp
> -rw-rw-r--.  1 vagrant vagrant   734 Jul  5 06:03 gmock_sources.cc
> -rw-rw-r--.  1 vagrant vagrant 25657 Jul  5 06:03 Makefile
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MESOS-7758) Stout doesn't build standalone.

2017-07-05 Thread James Peach (JIRA) 
James Peach created MESOS-7758:
--

 Summary: Stout doesn't build standalone.
 Key: MESOS-7758
 URL: https://issues.apache.org/jira/browse/MESOS-7758
 Project: Mesos
  Issue Type: Bug
  Components: build, stout
Reporter: James Peach


Stout doesn't build in a standalone configuration:

{noformat}
$ cd ~/src/mesos/3rdparty/stout
$ ./bootstrap

$ cd ~/build/stout
$ ~/src/mesos/3rdparty/stout/configure
...
$ make
...
make[1]: Leaving directory '/home/vagrant/build/stout/3rdparty'
make[1]: Entering directory '/home/vagrant/build/stout/3rdparty'
make[1]: *** No rule to make target 'googlemock-build-stamp'.  Stop.
make[1]: Leaving directory '/home/vagrant/build/stout/3rdparty'
make: *** [Makefile:1902: 
3rdparty/googletest-release-1.8.0/googlemock-build-stamp] Error 2
{noformat}

Note that the build expects 
{{3rdparty/googletest-release-1.8.0/googlemock-build-stamp}}, but 
{{googletest}} hasn't been staged yet:

{noformat}
[vagrant@fedora-26 stout]$ ls -l 3rdparty/
total 44
drwxr-xr-x.  3 vagrant vagrant  4096 Jan 18  2016 boost-1.53.0
-rw-rw-r--.  1 vagrant vagrant 0 Jul  5 06:16 boost-1.53.0-stamp
drwxrwxr-x.  8 vagrant vagrant  4096 Aug 15  2016 elfio-3.2
-rw-rw-r--.  1 vagrant vagrant 0 Jul  5 06:16 elfio-3.2-stamp
drwxr-xr-x. 10 vagrant vagrant  4096 Jul  5 06:16 glog-0.3.3
-rw-rw-r--.  1 vagrant vagrant 0 Jul  5 06:16 glog-0.3.3-build-stamp
-rw-rw-r--.  1 vagrant vagrant 0 Jul  5 06:16 glog-0.3.3-stamp
-rw-rw-r--.  1 vagrant vagrant   734 Jul  5 06:03 gmock_sources.cc
-rw-rw-r--.  1 vagrant vagrant 25657 Jul  5 06:03 Makefile
{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)