[jira] [Comment Edited] (MESOS-3973) Failing 'make distcheck' on Mac OS X 10.10.5, also 10.11.

2019-03-07 Thread Chun-Hung Hsiao (JIRA)


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

Chun-Hung Hsiao edited comment on MESOS-3973 at 3/8/19 2:13 AM:


I cannot reproduce it by {{make distcheck}} from the artifact generated by 
{{make distcheck}} either. [~alexr] Can you provide the steps you used to 
reproduce the error?


was (Author: chhsia0):
I cannot reproduce it by building from the artifact generated by {{make 
distcheck}} either. [~alexr] Can you provide the steps you used to reproduce 
the error?

> Failing 'make distcheck' on Mac OS X 10.10.5, also 10.11.
> -
>
> Key: MESOS-3973
> URL: https://issues.apache.org/jira/browse/MESOS-3973
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Affects Versions: 0.21.0, 0.21.2, 0.22.0, 0.23.0, 0.24.0, 0.25.0, 0.26.0
> Environment: Mac OS X 10.10.5, Clang 7.0.0.
>Reporter: Bernd Mathiske
>Priority: Major
>  Labels: build, build-failure, mesosphere
> Attachments: dist_check.log
>
>
> Non-root 'make distcheck.
> {noformat}
> ...
> [--] Global test environment tear-down
> [==] 826 tests from 113 test cases ran. (276624 ms total)
> [  PASSED  ] 826 tests.
>   YOU HAVE 6 DISABLED TESTS
> Making install in .
> make[3]: Nothing to be done for `install-exec-am'.
>  ../install-sh -c -d 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/lib/pkgconfig'
>  /usr/bin/install -c -m 644 mesos.pc 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/lib/pkgconfig'
> Making install in 3rdparty
> /Applications/Xcode.app/Contents/Developer/usr/bin/make  install-recursive
> Making install in libprocess
> Making install in 3rdparty
> /Applications/Xcode.app/Contents/Developer/usr/bin/make  install-recursive
> Making install in stout
> Making install in .
> make[9]: Nothing to be done for `install-exec-am'.
> make[9]: Nothing to be done for `install-data-am'.
> Making install in include
> make[9]: Nothing to be done for `install-exec-am'.
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/install-sh -c -d 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/include'
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/install-sh -c -d 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/include/stout'
>  /usr/bin/install -c -m 644  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/abort.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/attributes.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/base64.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/bits.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/bytes.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/cache.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/check.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/duration.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/dynamiclibrary.hpp
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/error.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/exit.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/flags.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/foreach.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/format.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/fs.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/gtest.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/gzip.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/hashmap.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/hashset.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/interval.hpp
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/lambda.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/linkedhashmap.hpp
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/list.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/mac.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/multihashmap.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/multimap.hpp
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/net.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/none.hpp 
> 

[jira] [Commented] (MESOS-9460) Speculative operations may make master and allocator resource views out of sync.

2019-03-07 Thread Greg Mann (JIRA)


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

Greg Mann commented on MESOS-9460:
--

Sharing some learnings here after a couple difficult attempts at resolving this 
issue:

The most recent reviews attempt to add a {{Sequence}} to the master which 
prevents problematic interleavings between multiple updates to the 
allocator/master state. Due to recent changes which added the concept of 
"orphan operations" (MESOS-9542), it has become difficult to accomplish this 
with per-agent {{Sequence}}s, without some messy refactoring of functions like 
{{recoverFramework()}}. It's fairly straightforward to accomplish a fix with a 
global {{Sequence}} in the master, but this seems undesirable since, for 
example, all calls to {{updateOperationStatus()}} would need to be sequenced.

Since the orphan operation code is tech debt which can be removed once 
MESOS-9556 and MESOS-8582 are resolved, I'm hesitant to add more complexity to 
the code on top of the orphan operation handling. I think I would prefer to 
punt on the issue described in this ticket until those other issues are 
resolved, at which point we will be able to handle this one in a simpler way.

> Speculative operations may make master and allocator resource views out of 
> sync.
> 
>
> Key: MESOS-9460
> URL: https://issues.apache.org/jira/browse/MESOS-9460
> Project: Mesos
>  Issue Type: Bug
>  Components: agent, master
>Affects Versions: 1.5.1, 1.6.1, 1.7.0
>Reporter: Meng Zhu
>Assignee: Greg Mann
>Priority: Major
>  Labels: foundations
>
> When speculative operations (RESERVE, UNRESERVE, CREATE, DESTROY) are issued 
> via the master operator API, the master updates the allocator state in 
> {{Master::apply()}}, and then later updates its internal state in 
> {{Master::_apply}}. This means that other updates to the allocator may be 
> interleaved between these two continuations, causing the master state to be 
> out of sync with the allocator state.
> This bug could happen with the following sequence of events:
> - agent (re)registers with the master
> - multiple speculative operation calls are made to the master via the 
> operator API
> - the allocator is speculatively updated in 
> https://github.com/apache/mesos/blob/1d1af190b0eb674beecf20646d0b6ce082db4ed0/src/master/master.cpp#L11326
> - before agent resource gets updated, it sends `UpdateSlaveMessage` when 
> getting the (re)registered message if it has the capability 
> `RESOURCE_PROVIDER` or oversubscription is used 
> (https://github.com/apache/mesos/blob/3badf7179992e61f30f5a79da9d481dd451c7c2f/src/slave/slave.cpp#L1560-L1566
>  and 
> https://github.com/apache/mesos/blob/3badf7179992e61f30f5a79da9d481dd451c7c2f/src/slave/slave.cpp#L1643-L1648)
> - as long as the first operation via the operator API has been added to the 
> {{Slave}} struct at this point, then the master won't hit [this block 
> here|https://github.com/apache/mesos/blob/1d1af190b0eb674beecf20646d0b6ce082db4ed0/src/master/master.cpp#L7940-L7945]
>  and the `UpdateSlaveMessage` triggers allocator to update the total 
> resources with STALE info from the {{Slave}} struct 
> [here|https://github.com/apache/mesos/blob/1d1af190b0eb674beecf20646d0b6ce082db4ed0/src/master/master.cpp#L8207],
>  thus the update from the previous operation is overwritten and LOST. Since 
> the {{Slave}} struct has not yet been updated, the allocator update at that 
> point uses stale resources from {{slave->totalResources}}.
> - agent finishes the operation and informs the master through 
> `UpdateOperationStatusMessage` but for the speculative operation, we do not 
> update the allocator 
> https://github.com/apache/mesos/blob/3badf7179992e61f30f5a79da9d481dd451c7c2f/src/master/master.cpp#L11187-L11189
> - The resource views of the master/agent state and the allocator state are 
> now inconsistent
> This caused MESOS-7971 and likely MESOS-9458 as well. 
> It's unclear how this can be fixed in a reliable way. It's possible that 
> ensuring that updates to the allocator state and the master state are 
> performed in a single synchronous block of code could work, but in the case 
> of operator-initiated operations this is difficult. It may also be possible 
> to ensure consistency by ensuring that every time such updates are done in 
> the master, the allocator is updated before the master state.
> This ticket will be Done when a comprehensive solution for this issue is 
> designed. A subsequent ticket for actual implementation of that solution 
> should be filed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Issue Comment Deleted] (MESOS-8813) Support multiple tasks with different users can access a persistent volume.

2019-03-07 Thread Gilbert Song (JIRA)


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

Gilbert Song updated MESOS-8813:

Comment: was deleted

(was: commit a5b9f6e1cdb2ec26baf6e49706e1a0d59f3ce4d1
Author: Qian Zhang 
Date:   Thu Mar 7 16:42:16 2019 -0800

Updated UNPRIVILEGED_USER_PersistentVolumes to cover non-shared PV.

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

commit d0e13dd928b57ea6d8447b9b428487d2fc28380a
Author: Qian Zhang 
Date:   Thu Mar 7 16:42:14 2019 -0800

Updated ROOT_UNPRIVILEGED_USER_PersistentVolumes to cover non-shared PV.

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

commit 7d78aab8ee3d6047979617a4c18b1c7f05e1317a
Author: Qian Zhang 
Date:   Thu Mar 7 16:42:13 2019 -0800

Replaced reading mounttable with getting path gid in volume gid manager.

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

commit 0293cc2d4ce25b113b4f1b8a34b34a0655132f9b
Author: Qian Zhang 
Date:   Thu Mar 7 16:42:09 2019 -0800

Made volume gid manager allocate & deallocate gid to non-shared PV.

Review: https://reviews.apache.org/r/70137/)

> Support multiple tasks with different users can access a persistent volume.
> ---
>
> Key: MESOS-8813
> URL: https://issues.apache.org/jira/browse/MESOS-8813
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Qian Zhang
>Assignee: Qian Zhang
>Priority: Major
> Fix For: 1.8.0
>
>
> See [design 
> doc|https://docs.google.com/document/d/1QyeDDX4Zr9E-0jKMoPTzsGE-v4KWwjmnCR0l8V4Tq2U/edit#heading=h.f4x59l41lxwx]
>  for why we need to do this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (MESOS-9642) Avoid reading host mount table when allocating a gid in GIDManager.

2019-03-07 Thread Gilbert Song (JIRA)
Gilbert Song created MESOS-9642:
---

 Summary: Avoid reading host mount table when allocating a gid in 
GIDManager.
 Key: MESOS-9642
 URL: https://issues.apache.org/jira/browse/MESOS-9642
 Project: Mesos
  Issue Type: Improvement
  Components: containerization
Reporter: Gilbert Song
Assignee: Qian Zhang






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (MESOS-9641) Support GID manager with non-sharable persistent volume.

2019-03-07 Thread Gilbert Song (JIRA)
Gilbert Song created MESOS-9641:
---

 Summary: Support GID manager with non-sharable persistent volume.
 Key: MESOS-9641
 URL: https://issues.apache.org/jira/browse/MESOS-9641
 Project: Mesos
  Issue Type: Improvement
  Components: containerization
Reporter: Gilbert Song
Assignee: Qian Zhang






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MESOS-3973) Failing 'make distcheck' on Mac OS X 10.10.5, also 10.11.

2019-03-07 Thread Chun-Hung Hsiao (JIRA)


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

Chun-Hung Hsiao commented on MESOS-3973:


I cannot reproduce it by building from the artifact generated by {{make 
distcheck}} either. [~alexr] Can you provide the steps you used to reproduce 
the error?

> Failing 'make distcheck' on Mac OS X 10.10.5, also 10.11.
> -
>
> Key: MESOS-3973
> URL: https://issues.apache.org/jira/browse/MESOS-3973
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Affects Versions: 0.21.0, 0.21.2, 0.22.0, 0.23.0, 0.24.0, 0.25.0, 0.26.0
> Environment: Mac OS X 10.10.5, Clang 7.0.0.
>Reporter: Bernd Mathiske
>Priority: Major
>  Labels: build, build-failure, mesosphere
> Attachments: dist_check.log
>
>
> Non-root 'make distcheck.
> {noformat}
> ...
> [--] Global test environment tear-down
> [==] 826 tests from 113 test cases ran. (276624 ms total)
> [  PASSED  ] 826 tests.
>   YOU HAVE 6 DISABLED TESTS
> Making install in .
> make[3]: Nothing to be done for `install-exec-am'.
>  ../install-sh -c -d 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/lib/pkgconfig'
>  /usr/bin/install -c -m 644 mesos.pc 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/lib/pkgconfig'
> Making install in 3rdparty
> /Applications/Xcode.app/Contents/Developer/usr/bin/make  install-recursive
> Making install in libprocess
> Making install in 3rdparty
> /Applications/Xcode.app/Contents/Developer/usr/bin/make  install-recursive
> Making install in stout
> Making install in .
> make[9]: Nothing to be done for `install-exec-am'.
> make[9]: Nothing to be done for `install-data-am'.
> Making install in include
> make[9]: Nothing to be done for `install-exec-am'.
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/install-sh -c -d 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/include'
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/install-sh -c -d 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/include/stout'
>  /usr/bin/install -c -m 644  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/abort.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/attributes.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/base64.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/bits.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/bytes.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/cache.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/check.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/duration.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/dynamiclibrary.hpp
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/error.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/exit.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/flags.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/foreach.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/format.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/fs.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/gtest.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/gzip.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/hashmap.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/hashset.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/interval.hpp
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/lambda.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/linkedhashmap.hpp
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/list.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/mac.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/multihashmap.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/multimap.hpp
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/net.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/none.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/nothing.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/numify.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/option.hpp 
> 

[jira] [Created] (MESOS-9640) Add authorization support for `UPDATE_QUOTA` call.

2019-03-07 Thread Meng Zhu (JIRA)
Meng Zhu created MESOS-9640:
---

 Summary: Add authorization support for `UPDATE_QUOTA` call.
 Key: MESOS-9640
 URL: https://issues.apache.org/jira/browse/MESOS-9640
 Project: Mesos
  Issue Type: Improvement
Reporter: Meng Zhu
Assignee: Meng Zhu


For the new `UPDATE_QUOTA` call, we need to add the corresponding authorization 
support. Unfortunately, there is already an action named `update_quotas`. We 
can use `update_quota_configs` instead.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MESOS-3973) Failing 'make distcheck' on Mac OS X 10.10.5, also 10.11.

2019-03-07 Thread Chun-Hung Hsiao (JIRA)


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

Chun-Hung Hsiao commented on MESOS-3973:


I cannot reproduce this error through the following steps on Mac 10.14.2:
{noformat}
$ git clone https://github.com/apache/mesos mesos-1.8.0
$ cd mesos-1.8.0
$ autoreconf -fi
$ mkdir build
$ cd build
$ ../configure
$ make distcheck
{noformat}
However I do encounter the original error for {{distuninstallcheck}}.

Let me check if this happens when building from a tarball generated by, e.g., 
{{make dist}}.

> Failing 'make distcheck' on Mac OS X 10.10.5, also 10.11.
> -
>
> Key: MESOS-3973
> URL: https://issues.apache.org/jira/browse/MESOS-3973
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Affects Versions: 0.21.0, 0.21.2, 0.22.0, 0.23.0, 0.24.0, 0.25.0, 0.26.0
> Environment: Mac OS X 10.10.5, Clang 7.0.0.
>Reporter: Bernd Mathiske
>Priority: Major
>  Labels: build, build-failure, mesosphere
> Attachments: dist_check.log
>
>
> Non-root 'make distcheck.
> {noformat}
> ...
> [--] Global test environment tear-down
> [==] 826 tests from 113 test cases ran. (276624 ms total)
> [  PASSED  ] 826 tests.
>   YOU HAVE 6 DISABLED TESTS
> Making install in .
> make[3]: Nothing to be done for `install-exec-am'.
>  ../install-sh -c -d 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/lib/pkgconfig'
>  /usr/bin/install -c -m 644 mesos.pc 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/lib/pkgconfig'
> Making install in 3rdparty
> /Applications/Xcode.app/Contents/Developer/usr/bin/make  install-recursive
> Making install in libprocess
> Making install in 3rdparty
> /Applications/Xcode.app/Contents/Developer/usr/bin/make  install-recursive
> Making install in stout
> Making install in .
> make[9]: Nothing to be done for `install-exec-am'.
> make[9]: Nothing to be done for `install-data-am'.
> Making install in include
> make[9]: Nothing to be done for `install-exec-am'.
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/install-sh -c -d 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/include'
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/install-sh -c -d 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/include/stout'
>  /usr/bin/install -c -m 644  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/abort.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/attributes.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/base64.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/bits.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/bytes.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/cache.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/check.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/duration.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/dynamiclibrary.hpp
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/error.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/exit.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/flags.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/foreach.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/format.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/fs.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/gtest.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/gzip.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/hashmap.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/hashset.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/interval.hpp
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/lambda.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/linkedhashmap.hpp
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/list.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/mac.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/multihashmap.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/multimap.hpp
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/net.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/none.hpp 
> 

[jira] [Commented] (MESOS-9610) Fetcher vulnerability - escaping from sandbox

2019-03-07 Thread Gilbert Song (JIRA)


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

Gilbert Song commented on MESOS-9610:
-

Probably we could create a separate JIRA to follow up on 
*ARCHIVE_EXTRACT_SECURE_NOABSOLUTEPATHS*?

cc [~mderela] [~kaysoky]

> Fetcher vulnerability - escaping from sandbox
> -
>
> Key: MESOS-9610
> URL: https://issues.apache.org/jira/browse/MESOS-9610
> Project: Mesos
>  Issue Type: Bug
>  Components: fetcher
>Affects Versions: 1.7.2
>Reporter: Mariusz Derela
>Assignee: Joseph Wu
>Priority: Blocker
>  Labels: bug, foundations, security-issue, vulnerabilities
> Fix For: 1.8.0, 1.7.3
>
>
> I have noticed that there is a possibility to exploit fetcher and  overwrite 
> any file on the agent host.
> scenario to reproduce:
> 1) prepare a file with any content and name a file like "../../../etc/test" 
> and archive it. We can use python and zipfile module to achieve that:
> {code:java}
> >>> import zipfile
> >>> zip = zipfile.ZipFile("exploit.zip", "w")
> >>> zip.writestr("../../../../../../../../../../../../etc/mariusz_was_here.txt",
> >>>  "some content")
> >>> zip.close()
> {code}
> 2) prepare a service that will use our artifact (exploit.zip)
> 3) run service
> at the end in /etc we will get our file. As you can imagine there is a lot 
> possibility how we can use it.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (MESOS-9639) Make CSI plugin RPC metrics agnostic to CSI versions.

2019-03-07 Thread Chun-Hung Hsiao (JIRA)
Chun-Hung Hsiao created MESOS-9639:
--

 Summary: Make CSI plugin RPC metrics agnostic to CSI versions.
 Key: MESOS-9639
 URL: https://issues.apache.org/jira/browse/MESOS-9639
 Project: Mesos
  Issue Type: Task
  Components: storage
Reporter: Chun-Hung Hsiao
Assignee: Chun-Hung Hsiao


Currently SLRP provides per-CSI-call metrics, e.g.:
{noformat}
resource_providers/./csi_plugin/rpcs/csi.v0.controller.CreateVolume/successes
resource_providers/./csi_plugin/rpcs/csi.v0.node.NodeGetId/errors
{noformat}
If we are to continue to provide such fine-grained metrics, when operators 
upgrade their CSI plugins to CSI v1, then SLRP would report another set of 
metrics for v1, which would be inconvenient to operators.

Also the fine-grained metrics are not very useful for operators, as most 
information are highly correlated to per-operation metrics. So most likely 
operators would simply aggregate the per-CSI-call metrics for monitoring CSI 
plugins, and use per-operation metrics to monitor volume creation/destroy/etc.

So instead of provide such fine-grained metrics, we could just provide a set of 
aggregated rpc metrics that are agnostic to CSI versions, such as:
{noformat}
resource_providers/./csi_plugin/rpcs_pending
resource_providers/./csi_plugin/rpcs_finished
resource_providers/./csi_plugin/rpcs_failed
resource_providers/./csi_plugin/rpcs_cancelled
{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (MESOS-9638) Mesos masters do no authenticate with agents.

2019-03-07 Thread Alexander Rukletsov (JIRA)
Alexander Rukletsov created MESOS-9638:
--

 Summary: Mesos masters do no authenticate with agents.
 Key: MESOS-9638
 URL: https://issues.apache.org/jira/browse/MESOS-9638
 Project: Mesos
  Issue Type: Improvement
  Components: agent, master
Reporter: Alexander Rukletsov


Currently Mesos agents do not verify that the messages they receive are coming 
from the leading master and haven't been tampered with. In untrusted 
environments this can be a source of security issues.

There are a couple of ways to fix this:
1) implement Master authentication on the transport or application level for 
each {{agent}}<->{{master}} connection (this might not be sufficient to 
distinguish a master from the leading master)
2) implement Master authentication on the transport level (for the connection 
to be encrypted) upon agent registration and pass a secret to the master for 
all subsequent, possibly separate and unencrypted, connections (the secret can 
be leaked on an unencrypted connection).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MESOS-9503) Exporting Mesos Cmake targets

2019-03-07 Thread Till Toenshoff (JIRA)


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

Till Toenshoff commented on MESOS-9503:
---

Right now CMake is not in feature parity with Autotools - for doing what you 
aim for it seems more practical to install Mesos using an Autotools build and 
then develop against the installed base (lib/headers).

> Exporting Mesos Cmake targets
> -
>
> Key: MESOS-9503
> URL: https://issues.apache.org/jira/browse/MESOS-9503
> Project: Mesos
>  Issue Type: Wish
>  Components: cmake
> Environment: OS: Dentos 7
>  Mesos: github master
>  build system: CMake & Ninja
>Reporter: Piotr Wera
>Priority: Major
>
> How to start new project with Mesos? 
>  I see only option is to inject my sources into Mesos sources.
>  Why still Mesos targets are not exported ?
>  I started with this and after some minor changes i stuck with grpc include 
> directories problem...
> {code:java}
> install(
> TARGETS 
> mesos;process;mesos-protobufs;stout;boost;elfio;picojson;rapidjson;grpc
> EXPORT mesos-cmake
> ARCHIVE DESTINATION lib/
> LIBRARY DESTINATION lib/
> RUNTIME DESTINATION bin/
> INCLUDES DESTINATION include)
> #install(
> #DIRECTORY ${PROJECT_SOURCE_DIR}/include/
> #DESTINATION include
> #FILES_MATCHING PATTERN "*.*hpp")
> install(
> EXPORT mesos-cmake
> FILE mesos-config.cmake
> NAMESPACE mesos::
> DESTINATION share/mesos/cmake)
> {code}
> Goal:
> {code:java}
> find_package(mesos 1.7.0 REQUIRED)
> add_executable(main main.cxx)
> target_link_libraries(main PRIVATE mesos::mesos)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MESOS-3973) Failing 'make distcheck' on Mac OS X 10.10.5, also 10.11.

2019-03-07 Thread Alexander Rukletsov (JIRA)


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

Alexander Rukletsov commented on MESOS-3973:


As of today, {{make distcheck}} for {{1.8.0-dev}} on Mac OS 10.13.6 still 
fails, while {{make check}} works. However, looking at the log, the problem now 
seems to be GRPC support. 
{noformat}
touch libev-4.22-build-stamp
../protobuf-3.5.0/src/protoc -I../../../3rdparty/libprocess/src/tests 
--cpp_out=. ../../../3rdparty/libprocess/src/tests/benchmarks.proto
../protobuf-3.5.0/src/protoc -I../../../3rdparty/libprocess/src/tests 
--grpc_out=. ../../../3rdparty/libprocess/src/tests/grpc_tests.proto
  \
  
--plugin=protoc-gen-grpc=../grpc-1.10.0/bins/opt/grpc_cpp_plugin
../protobuf-3.5.0/src/protoc -I../../../3rdparty/libprocess/src/tests 
--cpp_out=. ../../../3rdparty/libprocess/src/tests/grpc_tests.proto
/Library/Developer/CommandLineTools/usr/bin/make  distdir-am
 (cd include && /Library/Developer/CommandLineTools/usr/bin/make  
top_distdir=../../../mesos-1.8.0 
distdir=../../../mesos-1.8.0/3rdparty/libprocess/include \
 am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
/Library/Developer/CommandLineTools/usr/bin/make  distdir-am
/Library/Developer/CommandLineTools/usr/bin/make  \
  top_distdir="../../mesos-1.8.0" 
distdir="../../mesos-1.8.0/3rdparty/libprocess" \
  dist-hook
cp -r ../../../3rdparty/libprocess/3rdparty 
../../mesos-1.8.0/3rdparty/libprocess/
 (cd src && /Library/Developer/CommandLineTools/usr/bin/make  
top_distdir=../mesos-1.8.0 distdir=../mesos-1.8.0/src \
 am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
make[3]: *** No rule to make target `../include/csi/csi.grpc.pb.cc', needed by 
`distdir'.  Stop.
make[2]: *** [distdir-am] Error 1
make[1]: *** [distdir] Error 2
make: *** [dist] Error 2
{noformat}
[~chhsia0] any chance you have an idea why off the top of your head?

> Failing 'make distcheck' on Mac OS X 10.10.5, also 10.11.
> -
>
> Key: MESOS-3973
> URL: https://issues.apache.org/jira/browse/MESOS-3973
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Affects Versions: 0.21.0, 0.21.2, 0.22.0, 0.23.0, 0.24.0, 0.25.0, 0.26.0
> Environment: Mac OS X 10.10.5, Clang 7.0.0.
>Reporter: Bernd Mathiske
>Priority: Major
>  Labels: build, build-failure, mesosphere
> Attachments: dist_check.log
>
>
> Non-root 'make distcheck.
> {noformat}
> ...
> [--] Global test environment tear-down
> [==] 826 tests from 113 test cases ran. (276624 ms total)
> [  PASSED  ] 826 tests.
>   YOU HAVE 6 DISABLED TESTS
> Making install in .
> make[3]: Nothing to be done for `install-exec-am'.
>  ../install-sh -c -d 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/lib/pkgconfig'
>  /usr/bin/install -c -m 644 mesos.pc 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/lib/pkgconfig'
> Making install in 3rdparty
> /Applications/Xcode.app/Contents/Developer/usr/bin/make  install-recursive
> Making install in libprocess
> Making install in 3rdparty
> /Applications/Xcode.app/Contents/Developer/usr/bin/make  install-recursive
> Making install in stout
> Making install in .
> make[9]: Nothing to be done for `install-exec-am'.
> make[9]: Nothing to be done for `install-data-am'.
> Making install in include
> make[9]: Nothing to be done for `install-exec-am'.
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/install-sh -c -d 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/include'
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/install-sh -c -d 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/include/stout'
>  /usr/bin/install -c -m 644  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/abort.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/attributes.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/base64.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/bits.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/bytes.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/cache.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/check.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/duration.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/dynamiclibrary.hpp
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/error.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/exit.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/flags.hpp 
> 

[jira] [Created] (MESOS-9637) Impossible to CREATE a volume on resource provider resources over the operator API

2019-03-07 Thread Benjamin Bannier (JIRA)
Benjamin Bannier created MESOS-9637:
---

 Summary: Impossible to CREATE a volume on resource provider 
resources over the operator API
 Key: MESOS-9637
 URL: https://issues.apache.org/jira/browse/MESOS-9637
 Project: Mesos
  Issue Type: Bug
  Components: HTTP API, master
Reporter: Benjamin Bannier


Currently the master HTTP handler for operator API {{CREATE}} requests strips 
away the whole {{DiskInfo}} in any passed resources to calculate the consumed 
resources.

This is incorrect for resource provider disk resources where the {{DiskInfo}} 
contains information unrelated to the persistence. The handler should remove 
exclusively information created by the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (MESOS-9637) Impossible to CREATE a volume on resource provider resources over the operator API

2019-03-07 Thread Benjamin Bannier (JIRA)


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

Benjamin Bannier reassigned MESOS-9637:
---

Assignee: Benjamin Bannier

> Impossible to CREATE a volume on resource provider resources over the 
> operator API
> --
>
> Key: MESOS-9637
> URL: https://issues.apache.org/jira/browse/MESOS-9637
> Project: Mesos
>  Issue Type: Bug
>  Components: HTTP API, master
>Reporter: Benjamin Bannier
>Assignee: Benjamin Bannier
>Priority: Critical
>
> Currently the master HTTP handler for operator API {{CREATE}} requests strips 
> away the whole {{DiskInfo}} in any passed resources to calculate the consumed 
> resources.
> This is incorrect for resource provider disk resources where the {{DiskInfo}} 
> contains information unrelated to the persistence. The handler should remove 
> exclusively information created by the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


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

2019-03-07 Thread Alexander Rukletsov (JIRA)


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

Alexander Rukletsov reassigned MESOS-1776:
--

Assignee: (was: Kamil Domański)

> --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
>Priority: Major
>  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
(v7.6.3#76005)


[jira] [Assigned] (MESOS-1602) Add checks for unbundled libev

2019-03-07 Thread Alexander Rukletsov (JIRA)


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

Alexander Rukletsov reassigned MESOS-1602:
--

Assignee: (was: Timothy St. Clair)

> Add checks for unbundled libev
> --
>
> Key: MESOS-1602
> URL: https://issues.apache.org/jira/browse/MESOS-1602
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Affects Versions: 0.20.0
>Reporter: Timothy St. Clair
>Priority: Major
>
> Per review breakout a check to ensure libev has been compiled with 
> -DEV_CHILD_ENABLE=0
> Plus update checks for prefix'd installation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (MESOS-9636) Autotools improvements

2019-03-07 Thread Alexander Rukletsov (JIRA)
Alexander Rukletsov created MESOS-9636:
--

 Summary: Autotools improvements
 Key: MESOS-9636
 URL: https://issues.apache.org/jira/browse/MESOS-9636
 Project: Mesos
  Issue Type: Epic
  Components: build
Reporter: Alexander Rukletsov






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (MESOS-3973) Failing 'make distcheck' on Mac OS X 10.10.5, also 10.11.

2019-03-07 Thread Alexander Rukletsov (JIRA)


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

Alexander Rukletsov reassigned MESOS-3973:
--

Assignee: (was: Gilbert Song)

> Failing 'make distcheck' on Mac OS X 10.10.5, also 10.11.
> -
>
> Key: MESOS-3973
> URL: https://issues.apache.org/jira/browse/MESOS-3973
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Affects Versions: 0.21.0, 0.21.2, 0.22.0, 0.23.0, 0.24.0, 0.25.0, 0.26.0
> Environment: Mac OS X 10.10.5, Clang 7.0.0.
>Reporter: Bernd Mathiske
>Priority: Major
>  Labels: build, build-failure, mesosphere
> Attachments: dist_check.log
>
>
> Non-root 'make distcheck.
> {noformat}
> ...
> [--] Global test environment tear-down
> [==] 826 tests from 113 test cases ran. (276624 ms total)
> [  PASSED  ] 826 tests.
>   YOU HAVE 6 DISABLED TESTS
> Making install in .
> make[3]: Nothing to be done for `install-exec-am'.
>  ../install-sh -c -d 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/lib/pkgconfig'
>  /usr/bin/install -c -m 644 mesos.pc 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/lib/pkgconfig'
> Making install in 3rdparty
> /Applications/Xcode.app/Contents/Developer/usr/bin/make  install-recursive
> Making install in libprocess
> Making install in 3rdparty
> /Applications/Xcode.app/Contents/Developer/usr/bin/make  install-recursive
> Making install in stout
> Making install in .
> make[9]: Nothing to be done for `install-exec-am'.
> make[9]: Nothing to be done for `install-data-am'.
> Making install in include
> make[9]: Nothing to be done for `install-exec-am'.
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/install-sh -c -d 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/include'
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/install-sh -c -d 
> '/Users/bernd/mesos/mesos/build/mesos-0.26.0/_inst/include/stout'
>  /usr/bin/install -c -m 644  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/abort.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/attributes.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/base64.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/bits.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/bytes.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/cache.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/check.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/duration.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/dynamiclibrary.hpp
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/error.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/exit.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/flags.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/foreach.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/format.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/fs.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/gtest.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/gzip.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/hashmap.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/hashset.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/interval.hpp
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/ip.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/lambda.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/linkedhashmap.hpp
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/list.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/mac.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/multihashmap.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/multimap.hpp
>  ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/net.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/none.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/nothing.hpp
>  
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/numify.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/option.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp 
> ../../../../../../3rdparty/libprocess/3rdparty/stout/include/stout/path.hpp 

[jira] [Assigned] (MESOS-2092) Make ACLs dynamic

2019-03-07 Thread Alexander Rukletsov (JIRA)


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

Alexander Rukletsov reassigned MESOS-2092:
--

Assignee: (was: Yongqiao Wang)

> Make ACLs dynamic
> -
>
> Key: MESOS-2092
> URL: https://issues.apache.org/jira/browse/MESOS-2092
> Project: Mesos
>  Issue Type: Task
>  Components: security
>Reporter: Alexander Rukletsov
>Priority: Major
>  Labels: mesosphere, newbie
>
> Master loads ACLs once during its launch and there is no way to update them 
> in a running master. Making them dynamic will allow for updating ACLs on the 
> fly, for example granting a new framework necessary rights.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (MESOS-4036) Install instructions for CentOS 6.6 lead to errors running `perf`.

2019-03-07 Thread Alexander Rukletsov (JIRA)


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

Alexander Rukletsov reassigned MESOS-4036:
--

Assignee: Alexander Rukletsov

> Install instructions for CentOS 6.6 lead to errors running `perf`.
> --
>
> Key: MESOS-4036
> URL: https://issues.apache.org/jira/browse/MESOS-4036
> Project: Mesos
>  Issue Type: Improvement
> Environment: CentOS 6.6
>Reporter: Greg Mann
>Assignee: Alexander Rukletsov
>Priority: Minor
>  Labels: integration, mesosphere, newbie
>
> After using the current installation instructions in the getting started 
> documentation, {{perf}} will not run on CentOS 6.6 because the version of 
> elfutils included in devtoolset-2 is not compatible with the version of 
> {{perf}} installed by {{yum}}. Installing and using devtoolset-3, however 
> (http://linux.web.cern.ch/linux/scientific6/docs/softwarecollections.shtml) 
> fixes this issue. This could be resolved by updating the getting started 
> documentation to recommend installing devtoolset-3.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (MESOS-5588) Improve error handling when parsing acls.

2019-03-07 Thread Alexander Rukletsov (JIRA)


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

Alexander Rukletsov reassigned MESOS-5588:
--

Assignee: (was: Jörg Schad)

> Improve error handling when parsing acls.
> -
>
> Key: MESOS-5588
> URL: https://issues.apache.org/jira/browse/MESOS-5588
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Jörg Schad
>Priority: Major
>  Labels: mesosphere, security
>
> During parsing of the authorizer errors are ignored. This can lead to 
> undetected security issues.
> Consider the following acl with an typo (usr instead of user)
> {code}
>"view_frameworks": [
>   {
> "principals": { "type": "ANY" },
> "usr": { "type": "NONE" }
>   }
> ]
> {code}
> When the master is started with these flags it will interprete the acl int he 
> following way which gives any principal access to any framework.
> {noformat}
> view_frameworks {
>   principals {
> type: ANY
>   }
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MESOS-5027) Enable authenticated login in the webui

2019-03-07 Thread Alexander Rukletsov (JIRA)


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

Alexander Rukletsov commented on MESOS-5027:


Apparently, nothing grew out of the haosdent's attempt. Closing this as "won't 
do".

> Enable authenticated login in the webui
> ---
>
> Key: MESOS-5027
> URL: https://issues.apache.org/jira/browse/MESOS-5027
> Project: Mesos
>  Issue Type: Improvement
>  Components: master, security, webui
>Reporter: Greg Mann
>Assignee: haosdent
>Priority: Major
>  Labels: mesosphere, security
> Attachments: Screen Shot 2016-04-07 at 21.02.45.png
>
>
> The webui hits a number of endpoints to get the data that it displays: 
> {{/state}}, {{/metrics/snapshot}}, {{/files/browse}}, {{/files/read}}, and 
> maybe others? Once authentication is enabled on these endpoints, we need to 
> add a login prompt to the webui so that users can provide credentials.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)