[jira] [Commented] (MESOS-5390) v1 Executor Protos not included in maven jar
[ https://issues.apache.org/jira/browse/MESOS-5390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290574#comment-15290574 ] zhou xing commented on MESOS-5390: -- Review Request submitted at: https://reviews.apache.org/r/47582/ > v1 Executor Protos not included in maven jar > > > Key: MESOS-5390 > URL: https://issues.apache.org/jira/browse/MESOS-5390 > Project: Mesos > Issue Type: Bug > Components: HTTP API >Affects Versions: 0.28.0, 0.28.1 >Reporter: Ben Whitehead >Assignee: zhou xing > Labels: mesosphere > Fix For: 0.29.0 > > > According to MESOS-4793 the Executor v1 HTTP API was released in Mesos 0.28.0 > however the corresponding protos are not included in the maven jar for > version 0.28.0 or 0.28.1. > Script to verify > {code} > wget > https://repo.maven.apache.org/maven2/org/apache/mesos/mesos/0.28.1/mesos-0.28.1.jar > && unzip -lf mesos-0.28.1.jar | grep "v1\/executor" | wc -l > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-5390) v1 Executor Protos not included in maven jar
[ https://issues.apache.org/jira/browse/MESOS-5390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhou xing reassigned MESOS-5390: Assignee: zhou xing > v1 Executor Protos not included in maven jar > > > Key: MESOS-5390 > URL: https://issues.apache.org/jira/browse/MESOS-5390 > Project: Mesos > Issue Type: Bug > Components: HTTP API >Affects Versions: 0.28.0, 0.28.1 >Reporter: Ben Whitehead >Assignee: zhou xing > Labels: mesosphere > Fix For: 0.29.0 > > > According to MESOS-4793 the Executor v1 HTTP API was released in Mesos 0.28.0 > however the corresponding protos are not included in the maven jar for > version 0.28.0 or 0.28.1. > Script to verify > {code} > wget > https://repo.maven.apache.org/maven2/org/apache/mesos/mesos/0.28.1/mesos-0.28.1.jar > && unzip -lf mesos-0.28.1.jar | grep "v1\/executor" | wc -l > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-5335) Add authorization to GET /weights
[ https://issues.apache.org/jira/browse/MESOS-5335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhou xing reassigned MESOS-5335: Assignee: zhou xing > Add authorization to GET /weights > - > > Key: MESOS-5335 > URL: https://issues.apache.org/jira/browse/MESOS-5335 > Project: Mesos > Issue Type: Improvement > Components: master, security >Reporter: Adam B >Assignee: zhou xing > Labels: mesosphere, security > Fix For: 0.29.0 > > > We already authorize which http users can update weights for particular > roles, but even knowing of the existence of these roles (let alone their > weights) may be sensitive information. We should add authz around GET > operations on /weights. > Easy option: GET_ENDPOINT_WITH_PATH /weights > - Pro: No new verb > - Con: All or nothing > Complex option: GET_WEIGHTS_WITH_ROLE > - Pro: Filters contents based on roles the user is authorized to see > - Con: More authorize calls (one per role in each /weights request) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-5406) Validate ACLs on creating an instance of local authorizer.
[ https://issues.apache.org/jira/browse/MESOS-5406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Guo reassigned MESOS-5406: -- Assignee: Jay Guo > Validate ACLs on creating an instance of local authorizer. > -- > > Key: MESOS-5406 > URL: https://issues.apache.org/jira/browse/MESOS-5406 > Project: Mesos > Issue Type: Improvement >Reporter: Alexander Rukletsov >Assignee: Jay Guo > Labels: mesosphere, security > > Some combinations of ACLs are not allowed, for example, specifying both > {{SetQuota}} and {{UpdateQuota}}. We should capture such issues and error out > early. > This ticket aims to add as many validations as possible to a dedicated > {{validate()}} routine, instead of having them implicitly in the codebase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-3777) Replace Master/Slave Terminology Phase I - Modify public interfaces
[ https://issues.apache.org/jira/browse/MESOS-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] José Guilherme Vanz reassigned MESOS-3777: -- Assignee: José Guilherme Vanz > Replace Master/Slave Terminology Phase I - Modify public interfaces > > > Key: MESOS-3777 > URL: https://issues.apache.org/jira/browse/MESOS-3777 > Project: Mesos > Issue Type: Task >Reporter: Diana Arroyo >Assignee: José Guilherme Vanz > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2578) Add '{' on newline for function declarations in style checker
[ https://issues.apache.org/jira/browse/MESOS-2578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290353#comment-15290353 ] José Guilherme Vanz commented on MESOS-2578: I'll get a issue in the roadmap > Add '{' on newline for function declarations in style checker > - > > Key: MESOS-2578 > URL: https://issues.apache.org/jira/browse/MESOS-2578 > Project: Mesos > Issue Type: Improvement >Reporter: Niklas Quarfot Nielsen >Priority: Trivial > Labels: newbie > > Similar to MESOS-2577; another common style mistake is to not move curly > braces on a newline for function and class declarations: > {code} > class Foo { > void bar() { > ... > } > }; > {code} > vs > {code} > class Foo > { > void bar() > { > ... > } > }; > {code} > This should be easy to check with our style checker too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2578) Add '{' on newline for function declarations in style checker
[ https://issues.apache.org/jira/browse/MESOS-2578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] José Guilherme Vanz updated MESOS-2578: --- Assignee: (was: José Guilherme Vanz) > Add '{' on newline for function declarations in style checker > - > > Key: MESOS-2578 > URL: https://issues.apache.org/jira/browse/MESOS-2578 > Project: Mesos > Issue Type: Improvement >Reporter: Niklas Quarfot Nielsen >Priority: Trivial > Labels: newbie > > Similar to MESOS-2577; another common style mistake is to not move curly > braces on a newline for function and class declarations: > {code} > class Foo { > void bar() { > ... > } > }; > {code} > vs > {code} > class Foo > { > void bar() > { > ... > } > }; > {code} > This should be easy to check with our style checker too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1739) Allow slave reconfiguration on restart
[ https://issues.apache.org/jira/browse/MESOS-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290327#comment-15290327 ] Deshi Xiao commented on MESOS-1739: --- log adam's describe to understand the issue's background {quote} bq. Adam B 7 hours, 21 minutes ago (五月 18, 2016, 7:18 p.m.) Desired behavior: Operator can kill a slave process and restart it with new --attributes. Existing tasks will continue to run. No TASK_LOST or SLAVE_LOST message is sent. The slaveId remains the same. Outstanding offers from that slave will be rescinded, and those offers will be remade with the updated attributes. Current behavior 1: Operator shuts down a slave process, and restarts with --recover=cleanup, which kills all its tasks, clears the work_dir, and notifies the master that the old slaveId is "shutdown" and will never be reused again (SLAVE_LOST, offers rescinded, TASK_KILLED/LOST). Operator then restarts the slave with new --attributes, it gets a new slaveId, and new offers will be made with the new slaveId and updated attributes. Current behavior 2: Slave process dies/killed and tries to restart with new --attributes. Errors on recovery. Current behavior 3: Slave process dies/killed and doesn't reregister in slave_ping_timeout*max_slave_ping_timeouts (90s). Master considers it gone, sends SLAVE_LOST, TASK_LOST. Future attempts to reregister with the same slaveId fail. Slave must be cleaned up (tasks killed, work_dir removed) so it can register with a new slaveId (and new attributes). {quote} > Allow slave reconfiguration on restart > -- > > Key: MESOS-1739 > URL: https://issues.apache.org/jira/browse/MESOS-1739 > Project: Mesos > Issue Type: Epic >Reporter: Patrick Reilly > Labels: external-volumes, mesosphere, myriad > > Make it so that either via a slave restart or a out of process "reconfigure" > ping, the attributes and resources of a slave can be updated to be a superset > of what they used to be. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5408) Delete the /observe HTTP endpoint
[ https://issues.apache.org/jira/browse/MESOS-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290256#comment-15290256 ] Qian Zhang commented on MESOS-5408: --- Sure! Regards,Qian Zhang (张 乾) - Original message - From: "Vinod Kone (JIRA)" To: Qian AZ Zhang/China/IBM@IBMCN Cc: Subject: [jira] [Commented] (MESOS-5408) Delete the /observe HTTP endpoint Date: Thu, May 19, 2016 8:43 AM [ [1]https://issues.apache.org/jira/browse/MESOS-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290195#comment-15290195 ] Vinod Kone commented on MESOS-5408: --- Great. Please send an email to dev/user list as a heads up just in case and also update the CHANGELOG. -- This message was sent by Atlassian JIRA (v6.3.4#6332) [1] https://issues.apache.org/jira/browse/MESOS-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290195#comment-15290195 [2] https://issues.apache.org/jira/browse/MESOS-5408 > Delete the /observe HTTP endpoint > - > > Key: MESOS-5408 > URL: https://issues.apache.org/jira/browse/MESOS-5408 > Project: Mesos > Issue Type: Bug >Reporter: Vinod Kone >Assignee: Qian Zhang > > The "/observe" endpoint was introduced a long time ago for supporting > functionality that was never implemented. We should just kill this endpoint > and associated code to avoid tech debt. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5408) Delete the /observe HTTP endpoint
[ https://issues.apache.org/jira/browse/MESOS-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290195#comment-15290195 ] Vinod Kone commented on MESOS-5408: --- Great. Please send an email to dev/user list as a heads up just in case and also update the CHANGELOG. > Delete the /observe HTTP endpoint > - > > Key: MESOS-5408 > URL: https://issues.apache.org/jira/browse/MESOS-5408 > Project: Mesos > Issue Type: Bug >Reporter: Vinod Kone >Assignee: Qian Zhang > > The "/observe" endpoint was introduced a long time ago for supporting > functionality that was never implemented. We should just kill this endpoint > and associated code to avoid tech debt. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5408) Delete the /observe HTTP endpoint
[ https://issues.apache.org/jira/browse/MESOS-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290185#comment-15290185 ] Qian Zhang commented on MESOS-5408: --- [~vinodkone], I will work on it this week, thanks for shepherding. > Delete the /observe HTTP endpoint > - > > Key: MESOS-5408 > URL: https://issues.apache.org/jira/browse/MESOS-5408 > Project: Mesos > Issue Type: Bug >Reporter: Vinod Kone >Assignee: Qian Zhang > > The "/observe" endpoint was introduced a long time ago for supporting > functionality that was never implemented. We should just kill this endpoint > and associated code to avoid tech debt. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-5408) Delete the /observe HTTP endpoint
[ https://issues.apache.org/jira/browse/MESOS-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Qian Zhang reassigned MESOS-5408: - Assignee: Qian Zhang > Delete the /observe HTTP endpoint > - > > Key: MESOS-5408 > URL: https://issues.apache.org/jira/browse/MESOS-5408 > Project: Mesos > Issue Type: Bug >Reporter: Vinod Kone >Assignee: Qian Zhang > > The "/observe" endpoint was introduced a long time ago for supporting > functionality that was never implemented. We should just kill this endpoint > and associated code to avoid tech debt. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5412) Support CNI_ARGS
[ https://issues.apache.org/jira/browse/MESOS-5412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290167#comment-15290167 ] Qian Zhang commented on MESOS-5412: --- [~djosborne], Can you please elaborate what kind of policy you want to specify for the CNI plugin? > Support CNI_ARGS > > > Key: MESOS-5412 > URL: https://issues.apache.org/jira/browse/MESOS-5412 > Project: Mesos > Issue Type: Improvement > Components: containerization >Reporter: Dan Osborne > Fix For: 0.29.0 > > > Mesos-CNI should support the > [CNI_ARGS|https://github.com/containernetworking/cni/blob/master/SPEC.md#parameters] > field. > This would allow CNI plugins to be able to implement advanced networking > capabilities without needing modifications to Mesos. Current use case I am > facing: Allowing users to specify policy for their CNI plugin. > I'm proposing the following implementation: Pass a task's [NetworkInfo > Labels|https://github.com/apache/mesos/blob/b7e50fe8b20c96cda5546db5f2c2f47bee461edb/include/mesos/mesos.proto#L1732] > to the CNI plugin as CNI_ARGS. CNI args are simply key-value pairs split by > a '=', e.g. "FOO=BAR;ABC=123", which could be easily generated from the > NetworkInfo's key-value labels. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3932) Silence Boost compiler warnings with CMake
[ https://issues.apache.org/jira/browse/MESOS-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290048#comment-15290048 ] ASF GitHub Bot commented on MESOS-3932: --- Github user joerg84 commented on the pull request: https://github.com/apache/mesos/pull/104#issuecomment-220184401 Thanks for contributing to Mesos! Just some information about the review/contribute process at Mesos. We use ReviewBoard for reviews. Details can be found here: http://mesos.apache.org/documentation/latest/committing/ Looking forward to see your contributions there! > Silence Boost compiler warnings with CMake > -- > > Key: MESOS-3932 > URL: https://issues.apache.org/jira/browse/MESOS-3932 > Project: Mesos > Issue Type: Bug >Reporter: Neil Conway >Priority: Minor > Labels: cmake, mesosphere > > Per MESOS-3799, we should silence at least two kinds of compiler warning > fixes when including the Boost headers: > * Add -Wno-unused-local-typedefs to CXXFLAGS > * Use -isystem when including Boost to avoid deprecation warnings for use of > auto_ptr > I believe we technically need both, IIRC because some other depedencies pull > in Boost using their own -I flag. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3139) Incorporate CMake into standard documentation
[ https://issues.apache.org/jira/browse/MESOS-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290046#comment-15290046 ] ASF GitHub Bot commented on MESOS-3139: --- Github user joerg84 commented on the pull request: https://github.com/apache/mesos/pull/105#issuecomment-220184227 Thanks for adding documentation to Mesos! Just some information about the review/contribute process at Mesos. We use ReviewBoard for reviews. Details can be found here: http://mesos.apache.org/documentation/latest/committing/ Looking forward to see your contributions there! > Incorporate CMake into standard documentation > - > > Key: MESOS-3139 > URL: https://issues.apache.org/jira/browse/MESOS-3139 > Project: Mesos > Issue Type: Task > Components: cmake >Reporter: Alex Clemmer >Assignee: Alex Clemmer > Labels: build, cmake, mesosphere > > Right now it's anyone's guess how to build with CMake. If we want people to > use it, we should put up documentation. The central challenge is that the > CMake instructions will be slightly different for different platforms. > For example, on Linux, the gist of the build is basically the same as > autotools; you pull down the system dependencies (like APR, _etc_.), and then: > ``` > ./bootstrap > mkdir build-cmake && cd build-cmake > cmake .. > make > ``` > But, on Windows, it will be somewhat more complicated. There is no bootstrap > step, for example, because Windows doesn't have bash natively. And even when > we put that in, you'll still have to build the glog stuff out-of-band because > CMake has no way of booting up Visual Studio and calling "build." > So practically, we need to figure out: > * What our build story is for different platforms > * Write specific instructions for our "core" target platforms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5390) v1 Executor Protos not included in maven jar
[ https://issues.apache.org/jira/browse/MESOS-5390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Harutyunyan updated MESOS-5390: - Assignee: (was: Anand Mazumdar) > v1 Executor Protos not included in maven jar > > > Key: MESOS-5390 > URL: https://issues.apache.org/jira/browse/MESOS-5390 > Project: Mesos > Issue Type: Bug > Components: HTTP API >Affects Versions: 0.28.0, 0.28.1 >Reporter: Ben Whitehead > Labels: mesosphere > Fix For: 0.29.0 > > > According to MESOS-4793 the Executor v1 HTTP API was released in Mesos 0.28.0 > however the corresponding protos are not included in the maven jar for > version 0.28.0 or 0.28.1. > Script to verify > {code} > wget > https://repo.maven.apache.org/maven2/org/apache/mesos/mesos/0.28.1/mesos-0.28.1.jar > && unzip -lf mesos-0.28.1.jar | grep "v1\/executor" | wc -l > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2043) framework auth fail with timeout error and never get authenticated
[ https://issues.apache.org/jira/browse/MESOS-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Harutyunyan updated MESOS-2043: - Assignee: (was: Greg Mann) > framework auth fail with timeout error and never get authenticated > -- > > Key: MESOS-2043 > URL: https://issues.apache.org/jira/browse/MESOS-2043 > Project: Mesos > Issue Type: Bug > Components: master, scheduler driver, security, slave >Affects Versions: 0.21.0 >Reporter: Bhuvan Arumugam >Priority: Critical > Labels: mesosphere, security > Fix For: 0.29.0 > > Attachments: aurora-scheduler.20141104-1606-1706.log, master.log, > mesos-master.20141104-1606-1706.log, slave.log > > > I'm facing this issue in master as of > https://github.com/apache/mesos/commit/74ea59e144d131814c66972fb0cc14784d3503d4 > As [~adam-mesos] mentioned in IRC, this sounds similar to MESOS-1866. I'm > running 1 master and 1 scheduler (aurora). The framework authentication fail > due to time out: > error on mesos master: > {code} > I1104 19:37:17.741449 8329 master.cpp:3874] Authenticating > scheduler-d2d4437b-d375-4467-a583-362152fe065a@SCHEDULER_IP:8083 > I1104 19:37:17.741585 8329 master.cpp:3885] Using default CRAM-MD5 > authenticator > I1104 19:37:17.742106 8336 authenticator.hpp:169] Creating new server SASL > connection > W1104 19:37:22.742959 8329 master.cpp:3953] Authentication timed out > W1104 19:37:22.743548 8329 master.cpp:3930] Failed to authenticate > scheduler-d2d4437b-d375-4467-a583-362152fe065a@SCHEDULER_IP:8083: > Authentication discarded > {code} > scheduler error: > {code} > I1104 19:38:57.885486 49012 sched.cpp:283] Authenticating with master > master@MASTER_IP:PORT > I1104 19:38:57.885928 49002 authenticatee.hpp:133] Creating new client SASL > connection > I1104 19:38:57.890581 49007 authenticatee.hpp:224] Received SASL > authentication mechanisms: CRAM-MD5 > I1104 19:38:57.890656 49007 authenticatee.hpp:250] Attempting to authenticate > with mechanism 'CRAM-MD5' > W1104 19:39:02.891196 49005 sched.cpp:378] Authentication timed out > I1104 19:39:02.891850 49018 sched.cpp:338] Failed to authenticate with master > master@MASTER_IP:PORT: Authentication discarded > {code} > Looks like 2 instances {{scheduler-20f88a53-5945-4977-b5af-28f6c52d3c94}} & > {{scheduler-d2d4437b-d375-4467-a583-362152fe065a}} of same framework is > trying to authenticate and fail. > {code} > W1104 19:36:30.769420 8319 master.cpp:3930] Failed to authenticate > scheduler-20f88a53-5945-4977-b5af-28f6c52d3c94@SCHEDULER_IP:8083: Failed to > communicate with authenticatee > I1104 19:36:42.701441 8328 master.cpp:3860] Queuing up authentication > request from scheduler-d2d4437b-d375-4467-a583-362152fe065a@SCHEDULER_IP:8083 > because authentication is still in progress > {code} > Restarting master and scheduler didn't fix it. > This particular issue happen with 1 master and 1 scheduler after MESOS-1866 > is fixed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-5335) Add authorization to GET /weights
[ https://issues.apache.org/jira/browse/MESOS-5335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289853#comment-15289853 ] Alexander Rukletsov edited comment on MESOS-5335 at 5/18/16 9:23 PM: - This one should follow the same path we took in MESOS-5336. Once authorization filters land (MESOS-5403), we will be updating the implementation. was (Author: alexr): This one should follow the same path we take in MESOS-5336. Once authorization filters land (MESOS-5403), we will be updating the implementation. > Add authorization to GET /weights > - > > Key: MESOS-5335 > URL: https://issues.apache.org/jira/browse/MESOS-5335 > Project: Mesos > Issue Type: Improvement > Components: master, security >Reporter: Adam B > Labels: mesosphere, security > Fix For: 0.29.0 > > > We already authorize which http users can update weights for particular > roles, but even knowing of the existence of these roles (let alone their > weights) may be sensitive information. We should add authz around GET > operations on /weights. > Easy option: GET_ENDPOINT_WITH_PATH /weights > - Pro: No new verb > - Con: All or nothing > Complex option: GET_WEIGHTS_WITH_ROLE > - Pro: Filters contents based on roles the user is authorized to see > - Con: More authorize calls (one per role in each /weights request) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5335) Add authorization to GET /weights
[ https://issues.apache.org/jira/browse/MESOS-5335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289853#comment-15289853 ] Alexander Rukletsov commented on MESOS-5335: This one should follow the same path we take in MESOS-5336. Once authorization filters land (MESOS-5403), we will be updating the implementation. > Add authorization to GET /weights > - > > Key: MESOS-5335 > URL: https://issues.apache.org/jira/browse/MESOS-5335 > Project: Mesos > Issue Type: Improvement > Components: master, security >Reporter: Adam B > Labels: mesosphere, security > Fix For: 0.29.0 > > > We already authorize which http users can update weights for particular > roles, but even knowing of the existence of these roles (let alone their > weights) may be sensitive information. We should add authz around GET > operations on /weights. > Easy option: GET_ENDPOINT_WITH_PATH /weights > - Pro: No new verb > - Con: All or nothing > Complex option: GET_WEIGHTS_WITH_ROLE > - Pro: Filters contents based on roles the user is authorized to see > - Con: More authorize calls (one per role in each /weights request) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-1554) Persistent resources support for storage-like services
[ https://issues.apache.org/jira/browse/MESOS-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289835#comment-15289835 ] Adam B commented on MESOS-1554: --- [~mcypark], [~jieyu], what's left before we can say that "Persistent Volumes" has shipped? Can we move the unresolved tasks from this JIRA into a Persistent Volumes v2 Epic, so we can close this one out? > Persistent resources support for storage-like services > -- > > Key: MESOS-1554 > URL: https://issues.apache.org/jira/browse/MESOS-1554 > Project: Mesos > Issue Type: Epic > Components: general, hadoop >Reporter: Nikita Vetoshkin >Assignee: Michael Park >Priority: Critical > Labels: mesosphere, twitter > > This question came up in [dev mailing > list|http://mail-archives.apache.org/mod_mbox/mesos-dev/201406.mbox/%3CCAK8jAgNDs9Fe011Sq1jeNr0h%3DE-tDD9rak6hAsap3PqHx1y%3DKQ%40mail.gmail.com%3E]. > It seems reasonable for storage like services (e.g. HDFS or Cassandra) to use > Mesos to manage it's instances. But right now if we'd like to restart > instance (e.g. to spin up a new version) - all previous instance version > sandbox filesystem resources will be recycled by slave's garbage collector. > At the moment filesystem resources can be managed out of band - i.e. > instances can save their data in some database specific placed, that various > instances can share (e.g. {{/var/lib/cassandra}}). > [~benjaminhindman] suggested an idea in the mailing list (though it still > needs some fleshing out): > {quote} > The idea originally came about because, even today, if we allocate some > file system space to a task/executor, and then that task/executor > terminates, we haven't officially "freed" those file system resources until > after we garbage collect the task/executor sandbox! (We keep the sandbox > around so a user/operator can get the stdout/stderr or anything else left > around from their task/executor.) > To solve this problem we wanted to be able to let a task/executor terminate > but not *give up* all of it's resources, hence: persistent resources. > Pushing this concept even further you could imagine always reallocating > resources to a framework that had already been allocated those resources > for a previous task/executor. Looked at from another perspective, these are > "late-binding", or "lazy", resource reservations. > At one point in time we had considered just doing 'right-of-first-refusal' > for allocations after a task/executor terminate. But this is really > insufficient for supporting storage-like frameworks well (and likely even > harder to reliably implement then 'persistent resources' IMHO). > There are a ton of things that need to get worked out in this model, > including (but not limited to), how should a file system (or disk) be > exposed in order to be made persistent? How should persistent resources be > returned to a master? How many persistent resources can a framework get > allocated? > {quote} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2018) Dynamic Reservation
[ https://issues.apache.org/jira/browse/MESOS-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289832#comment-15289832 ] Adam B commented on MESOS-2018: --- [~mcypark], what's left before we can say that "Dynamic Reservations" has shipped? Can we move the unresolved tasks from this JIRA into a Dynamic Reservations v2 Epic, so we can close this one out? > Dynamic Reservation > --- > > Key: MESOS-2018 > URL: https://issues.apache.org/jira/browse/MESOS-2018 > Project: Mesos > Issue Type: Epic > Components: allocation, framework, master, slave >Reporter: Adam B >Assignee: Michael Park >Priority: Critical > Labels: mesosphere, offer, persistence, reservations, resource, > stateful, storage > > h3. Overview > This is a feature to provide better support for running stateful services on > Mesos such as HDFS (Distributed Filesystem), Cassandra (Distributed > Database), or MySQL (Local Database). > Current resource reservations (henceforth called "static" reservations) are > statically determined by the slave operator at slave start time, and > individual frameworks have no authority to reserve resources themselves. > Dynamic reservations allow a framework to dynamically reserve offered > resources, such that those resources will only be re-offered to the same > framework (or other frameworks with the same role). > This is especially useful if the framework's task stored some state on the > slave, and needs a guaranteed set of resources reserved so that it can > re-launch a task on the same slave to recover that state. > h3. Planned Stages > 1. MESOS-2489: Enable a framework to perform reservation operations. > The goal of this stage is to allow the framework to send back a > Reserve/Unreserve operation which gets validated by the master and updates > the allocator resources. The allocator's {{allocate}} logic is left unchanged > and the resources get offered back to the framework's role as desired. > 2. MESOS-2491: Persist the reservation state on the slave. > The goal of this stage is to persist the reservation state on the slave. > Currently the master knows to store the persistent volumes in the > {{checkpointedResources}} data structure which gets sent to individual slaves > to be checkpointed. We will update the master such that dynamically reserved > resources are stored in the {{checkpointedResources}} as well. This stage > also involves subtasks such as updating the slave re(register) logic to > support slave re-starts. > 3. MESOS-2600: Introduce reservation HTTP endpoints on the master. > The goal of this stage is to enable operators to perform reservation > operations via HTTP endpoints on the master. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4886) Support mesos containerizer force_pull_image option.
[ https://issues.apache.org/jira/browse/MESOS-4886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilbert Song updated MESOS-4886: Sprint: Mesosphere Sprint 35 Story Points: 3 Labels: containerizer mesosphere (was: containerizer) Fix Version/s: 0.29.0 > Support mesos containerizer force_pull_image option. > > > Key: MESOS-4886 > URL: https://issues.apache.org/jira/browse/MESOS-4886 > Project: Mesos > Issue Type: Improvement > Components: containerization >Reporter: Gilbert Song >Assignee: Guangya Liu > Labels: containerizer, mesosphere > Fix For: 0.29.0 > > > Currently for unified containerizer, images that are already cached by > metadata manager cannot be updated. User has to delete corresponding images > in store if an update is need. We should support `force_pull_image` option > for unified containerizer, to provide override option if existed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5412) Support CNI_ARGS
Dan Osborne created MESOS-5412: -- Summary: Support CNI_ARGS Key: MESOS-5412 URL: https://issues.apache.org/jira/browse/MESOS-5412 Project: Mesos Issue Type: Improvement Components: containerization Reporter: Dan Osborne Fix For: 0.29.0 Mesos-CNI should support the [CNI_ARGS](https://github.com/containernetworking/cni/blob/master/SPEC.md#parameters) field. This would allow CNI plugins to be able to implement advanced networking capabilities without needing modifications to Mesos. Current use case I am facing: Allowing users to specify policy for their CNI plugin. I'm proposing the following implementation: Pass a task's [NetworkInfo Labels](https://github.com/apache/mesos/blob/b7e50fe8b20c96cda5546db5f2c2f47bee461edb/include/mesos/mesos.proto#L1732) to the CNI plugin as CNI_ARGS. CNI args are simply key-value pairs split by a '=', e.g. "FOO=BAR;ABC=123", which could be easily generated from the NetworkInfo's key-value labels. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5412) Support CNI_ARGS
[ https://issues.apache.org/jira/browse/MESOS-5412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Osborne updated MESOS-5412: --- Description: Mesos-CNI should support the [CNI_ARGS|https://github.com/containernetworking/cni/blob/master/SPEC.md#parameters] field. This would allow CNI plugins to be able to implement advanced networking capabilities without needing modifications to Mesos. Current use case I am facing: Allowing users to specify policy for their CNI plugin. I'm proposing the following implementation: Pass a task's [NetworkInfo Labels|https://github.com/apache/mesos/blob/b7e50fe8b20c96cda5546db5f2c2f47bee461edb/include/mesos/mesos.proto#L1732] to the CNI plugin as CNI_ARGS. CNI args are simply key-value pairs split by a '=', e.g. "FOO=BAR;ABC=123", which could be easily generated from the NetworkInfo's key-value labels. was: Mesos-CNI should support the [CNI_ARGS](https://github.com/containernetworking/cni/blob/master/SPEC.md#parameters) field. This would allow CNI plugins to be able to implement advanced networking capabilities without needing modifications to Mesos. Current use case I am facing: Allowing users to specify policy for their CNI plugin. I'm proposing the following implementation: Pass a task's [NetworkInfo Labels](https://github.com/apache/mesos/blob/b7e50fe8b20c96cda5546db5f2c2f47bee461edb/include/mesos/mesos.proto#L1732) to the CNI plugin as CNI_ARGS. CNI args are simply key-value pairs split by a '=', e.g. "FOO=BAR;ABC=123", which could be easily generated from the NetworkInfo's key-value labels. > Support CNI_ARGS > > > Key: MESOS-5412 > URL: https://issues.apache.org/jira/browse/MESOS-5412 > Project: Mesos > Issue Type: Improvement > Components: containerization >Reporter: Dan Osborne > Fix For: 0.29.0 > > > Mesos-CNI should support the > [CNI_ARGS|https://github.com/containernetworking/cni/blob/master/SPEC.md#parameters] > field. > This would allow CNI plugins to be able to implement advanced networking > capabilities without needing modifications to Mesos. Current use case I am > facing: Allowing users to specify policy for their CNI plugin. > I'm proposing the following implementation: Pass a task's [NetworkInfo > Labels|https://github.com/apache/mesos/blob/b7e50fe8b20c96cda5546db5f2c2f47bee461edb/include/mesos/mesos.proto#L1732] > to the CNI plugin as CNI_ARGS. CNI args are simply key-value pairs split by > a '=', e.g. "FOO=BAR;ABC=123", which could be easily generated from the > NetworkInfo's key-value labels. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5310) Enable `network/cni` isolator to allow modifications and deletion of CNI config
[ https://issues.apache.org/jira/browse/MESOS-5310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avinash Sridharan updated MESOS-5310: - Summary: Enable `network/cni` isolator to allow modifications and deletion of CNI config (was: Enable `network/cni` isolator to load CNI config at runtime. ) > Enable `network/cni` isolator to allow modifications and deletion of CNI > config > --- > > Key: MESOS-5310 > URL: https://issues.apache.org/jira/browse/MESOS-5310 > Project: Mesos > Issue Type: Task > Components: containerization > Environment: linux >Reporter: Avinash Sridharan >Assignee: Qian Zhang > Labels: mesosphere > > Currently the `network/cni` isolator can only load the CNI configs at > startup. This makes the CNI networks immutable. From an operational > standpoint this can make deployments painful for operators. > To make CNI more flexible the `network/cni` isolator should be able to load > configs at run time. > The proposal is to add an endpoint to the `network/cni` isolator, to which > when the operator sends a PUT request the `network/cni` isolator will reload > CNI configs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5195) Docker executor: task logs lost on shutdown
[ https://issues.apache.org/jira/browse/MESOS-5195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289598#comment-15289598 ] Vinod Kone commented on MESOS-5195: --- [~timchen] Can you shepherd this? > Docker executor: task logs lost on shutdown > --- > > Key: MESOS-5195 > URL: https://issues.apache.org/jira/browse/MESOS-5195 > Project: Mesos > Issue Type: Bug > Components: containerization, docker >Affects Versions: 0.27.2 > Environment: Linux 4.4.2 "Ubuntu 14.04.2 LTS" >Reporter: Steven Schlansker > > When you try to kill a task running in the Docker executor (in our case via > Singularity), the task shuts down cleanly but the last logs to standard out / > standard error are lost in teardown. > For example, we run dumb-init. With debugging on, you can see it should > write: > {noformat} > DEBUG("Forwarded signal %d to children.\n", signum); > {noformat} > If you attach strace to the process, you can see it clearly writes the text > to stderr. But that message is lost and never is written to the sandbox > 'stderr' file. > We believe the issue starts here, in Docker executor.cpp: > {code} > void shutdown(ExecutorDriver* driver) > { > cout << "Shutting down" << endl; > if (run.isSome() && !killed) { > // The docker daemon might still be in progress starting the > // container, therefore we kill both the docker run process > // and also ask the daemon to stop the container. > // Making a mutable copy of the future so we can call discard. > Future(run.get()).discard(); > stop = docker->stop(containerName, stopTimeout); > killed = true; > } > } > {code} > Notice how the "run" future is discarded *before* the Docker daemon is told > to stop -- now what will discarding it do? > {code} > void commandDiscarded(const Subprocess& s, const string& cmd) > { > VLOG(1) << "'" << cmd << "' is being discarded"; > os::killtree(s.pid(), SIGKILL); > } > {code} > Oops, just sent SIGKILL to the entire process tree... > You can see another (harmless?) side effect in the Docker daemon logs, it > never gets a chance to kill the task: > {noformat} > ERROR Handler for DELETE > /v1.22/containers/mesos-f3bb39fe-8fd9-43d2-80a6-93df6a76807e-S2.0c509380-c326-4ff7-bb68-86a37b54f233 > returned error: No such container: > mesos-f3bb39fe-8fd9-43d2-80a6-93df6a76807e-S2.0c509380-c326-4ff7-bb68-86a37b54f233 > {noformat} > I suspect that the fix is wait for 'docker->stop()' to complete before > discarding the 'run' future. > Happy to provide more information if necessary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-3690) Make Apache Mesos' website mobile friendly
[ https://issues.apache.org/jira/browse/MESOS-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent updated MESOS-3690: Attachment: home_tablet.gif home_pc.gif home_mobile.gif > Make Apache Mesos' website mobile friendly > -- > > Key: MESOS-3690 > URL: https://issues.apache.org/jira/browse/MESOS-3690 > Project: Mesos > Issue Type: Improvement > Components: project website >Reporter: Freddy Ayuso-Henson >Priority: Minor > Attachments: home_mobile.gif, home_pc.gif, home_tablet.gif > > > Changes to the project website: > - Support smaller screens/devices (mobile) > - Limit images' max width when displayed > - Update Bootstrap version > - Other smaller changes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5317) Authorize the agent's '/containers' endpoint
[ https://issues.apache.org/jira/browse/MESOS-5317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289378#comment-15289378 ] Abhishek Dasgupta commented on MESOS-5317: -- RR: https://reviews.apache.org/r/47530/ > Authorize the agent's '/containers' endpoint > > > Key: MESOS-5317 > URL: https://issues.apache.org/jira/browse/MESOS-5317 > Project: Mesos > Issue Type: Improvement > Components: security, slave >Reporter: Greg Mann >Assignee: Abhishek Dasgupta > Labels: authorization, mesosphere > Fix For: 0.29.0 > > > After the agent's {{/containers}} endpoint is authenticated, we should > enabled authorization as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5155) Consolidate authorization actions for quota.
[ https://issues.apache.org/jira/browse/MESOS-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289240#comment-15289240 ] Alexander Rukletsov commented on MESOS-5155: {noformat} Commit: a28917f188183a4be1c974fc61ef20797cf255af [a28917f] Author: Zhitao Li Date: 18 May 2016 16:17:11 CEST Committer: Alexander Rukletsov Commit Date: 18 May 2016 18:21:40 CEST Used UPDATE_QUOTA_WITH_ROLE for both quota set and remove. To consolidate authorization actions for quota, we introduce a new authorization action `UPDATE_QUOTA_WITH_ROLE` and corresponding ACL. They new action and ACL should be used instead of now deprecated `SET_QUOTA_WITH_ROLE` and `DESTROY_QUOTA_WITH_PRINCIPAL`. Until the end of the deprecation cycle, we will be using both combinations by querying the authorizer twice. Review: https://reviews.apache.org/r/47399/ {noformat} > Consolidate authorization actions for quota. > > > Key: MESOS-5155 > URL: https://issues.apache.org/jira/browse/MESOS-5155 > Project: Mesos > Issue Type: Improvement >Reporter: Alexander Rukletsov >Assignee: Zhitao Li > Labels: mesosphere > > We should have just a single authz action: {{UPDATE_QUOTA_WITH_ROLE}}. It was > a mistake in retrospect to introduce multiple actions. > Actions that are not symmetrical are register/teardown and dynamic > reservations. The way they are implemented in this way is because entities > that do one action differ from entities that do the other. For example, > register framework is issued by a framework, teardown by an operator. What is > a good way to identify a framework? A role it runs in, which may be different > each launch and makes no sense in multi-role frameworks setup or better a > sort of a group id, which is its principal. For dynamic reservations and > persistent volumes, they can be both issued by frameworks and operators, > hence similar reasoning applies. > Now, quota is associated with a role and set only by operators. Do we need to > care about principals that set it? Not that much. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3139) Incorporate CMake into standard documentation
[ https://issues.apache.org/jira/browse/MESOS-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15288974#comment-15288974 ] ASF GitHub Bot commented on MESOS-3139: --- GitHub user frankscholten opened a pull request: https://github.com/apache/mesos/pull/105 MESOS-3139 Added first draft CMake build docs. You can merge this pull request into a Git repository by running: $ git pull https://github.com/frankscholten/mesos MESOS-3139 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/mesos/pull/105.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #105 commit 8dd43009c6ba5db07acff4938c92747a97fde156 Author: Frank Scholten Date: 2016-05-18T13:34:49Z Added first draft CMake build docs. > Incorporate CMake into standard documentation > - > > Key: MESOS-3139 > URL: https://issues.apache.org/jira/browse/MESOS-3139 > Project: Mesos > Issue Type: Task > Components: cmake >Reporter: Alex Clemmer >Assignee: Alex Clemmer > Labels: build, cmake, mesosphere > > Right now it's anyone's guess how to build with CMake. If we want people to > use it, we should put up documentation. The central challenge is that the > CMake instructions will be slightly different for different platforms. > For example, on Linux, the gist of the build is basically the same as > autotools; you pull down the system dependencies (like APR, _etc_.), and then: > ``` > ./bootstrap > mkdir build-cmake && cd build-cmake > cmake .. > make > ``` > But, on Windows, it will be somewhat more complicated. There is no bootstrap > step, for example, because Windows doesn't have bash natively. And even when > we put that in, you'll still have to build the glog stuff out-of-band because > CMake has no way of booting up Visual Studio and calling "build." > So practically, we need to figure out: > * What our build story is for different platforms > * Write specific instructions for our "core" target platforms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5395) Task getting stuck in staging state if launch it on a rebooted slave.
[ https://issues.apache.org/jira/browse/MESOS-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mengkui gong updated MESOS-5395: Attachment: mesos-log.zip Hello Wu, Thank you very much for your reply ! Please find the attached log file. Br, Mengkui > Task getting stuck in staging state if launch it on a rebooted slave. > - > > Key: MESOS-5395 > URL: https://issues.apache.org/jira/browse/MESOS-5395 > Project: Mesos > Issue Type: Bug >Affects Versions: 0.28.0 > Environment: mesos/marathon cluster, 3 maters/4 slaves > Mesos: 0.28.0 , Marathon 0.15.2 >Reporter: Mengkui gong > Attachments: mesos-log.zip > > > if rebooting a slave, after that, using Marathon to launch a task, the task > can start on other slaves without problem. But if launch it on the rebooted > slave, the task will be stuck. From Mesos UI shows it in staging state from > active tasks list. From Marathon UI shows it in deploying state. It can > keeping in stuck state for more than 2 hours. After that time, Marathon will > automatically launch the task on this rebooted slave or other slave as > normal. So the rebooted slave be recovered as well after that time. > From Mesos log, I can see "telling slave to kill task" all the time. > I0517 15:25:27.207237 20568 master.cpp:3826] Telling slave > 282745ab-423a-4350-a449-3e8cdfccfb93-S1 at slave(1)@10.254.234.236:5050 > (mesos-slave-3) to kill task > project-hub_project-hub-frontend.b645f24b-1c1f-11e6-bb25-d00d2cce797e of > framework 17cd3756-1d59-4dfc-984d-3fe09f6b5730- (marathon) at > scheduler-fe615b72-ab92-49ca-89e6-e74e600c7e15@10.254.228.3:56757. > From rebooted slave log, I can see: > May 17 15:28:37 euca-10-254-234-236 mesos-slave[829]: I0517 15:28:37.206831 > 916 slave.cpp:1891] Asked to kill task > project-hub_project-hub-frontend.b645f24b-1c1f-11e6-bb25-d00d2cce797e of > framework 17cd3756-1d59-4dfc-984d-3fe09f6b5730- > May 17 15:28:37 euca-10-254-234-236 mesos-slave[829]: W0517 15:28:37.206866 > 916 slave.cpp:2018] Ignoring kill task > project-hub_project-hub-frontend.b645f24b-1c1f-11e6-bb25-d00d2cce797e because > the executor > 'project-hub_project-hub-frontend.b645f24b-1c1f-11e6-bb25-d00d2cce797e' of > framework 17cd3756-1d59-4dfc-984d-3fe09f6b5730- is terminating/terminated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3932) Silence Boost compiler warnings with CMake
[ https://issues.apache.org/jira/browse/MESOS-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15288873#comment-15288873 ] ASF GitHub Bot commented on MESOS-3932: --- GitHub user frankscholten opened a pull request: https://github.com/apache/mesos/pull/104 MESOS-3932 Suppressed boost auto_ptr compile warnings. You can merge this pull request into a Git repository by running: $ git pull https://github.com/frankscholten/mesos MESOS-3932 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/mesos/pull/104.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #104 commit 4fbe309be6b17f65cb2ad7c0dde0967ed3643b72 Author: Frank Scholten Date: 2016-05-18T12:21:49Z Suppressed boost auto_ptr compile warnings. > Silence Boost compiler warnings with CMake > -- > > Key: MESOS-3932 > URL: https://issues.apache.org/jira/browse/MESOS-3932 > Project: Mesos > Issue Type: Bug >Reporter: Neil Conway >Priority: Minor > Labels: cmake, mesosphere > > Per MESOS-3799, we should silence at least two kinds of compiler warning > fixes when including the Boost headers: > * Add -Wno-unused-local-typedefs to CXXFLAGS > * Use -isystem when including Boost to avoid deprecation warnings for use of > auto_ptr > I believe we technically need both, IIRC because some other depedencies pull > in Boost using their own -I flag. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5411) SSL support in Mesos Packages
[ https://issues.apache.org/jira/browse/MESOS-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Śliwka updated MESOS-5411: Summary: SSL support in Mesos Packages (was: SSL support in Mesos Debian Packages) > SSL support in Mesos Packages > - > > Key: MESOS-5411 > URL: https://issues.apache.org/jira/browse/MESOS-5411 > Project: Mesos > Issue Type: Improvement >Reporter: Piotr Śliwka >Priority: Minor > > It would be nice to have the SSL support (as described in > http://mesos.apache.org/documentation/latest/ssl/) compiled into official > deb/rpm packages, so that using this feature would not require custom builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5411) SSL support in Mesos Debian Packages
[ https://issues.apache.org/jira/browse/MESOS-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Śliwka updated MESOS-5411: Description: It would be nice to have the SSL support (as described in http://mesos.apache.org/documentation/latest/ssl/) compiled into official deb/rpm packages, so that using this feature would not require custom builds. (was: It would be nice to have the SSL support (as described in http://mesos.apache.org/documentation/latest/ssl/) compiled into official Debian packages, so that using this feature would not require custom builds.) > SSL support in Mesos Debian Packages > > > Key: MESOS-5411 > URL: https://issues.apache.org/jira/browse/MESOS-5411 > Project: Mesos > Issue Type: Improvement >Reporter: Piotr Śliwka >Priority: Minor > > It would be nice to have the SSL support (as described in > http://mesos.apache.org/documentation/latest/ssl/) compiled into official > deb/rpm packages, so that using this feature would not require custom builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5411) SSL support in Mesos Debian Packages
Piotr Śliwka created MESOS-5411: --- Summary: SSL support in Mesos Debian Packages Key: MESOS-5411 URL: https://issues.apache.org/jira/browse/MESOS-5411 Project: Mesos Issue Type: Improvement Reporter: Piotr Śliwka Priority: Minor It would be nice to have the SSL support (as described in http://mesos.apache.org/documentation/latest/ssl/) compiled into official Debian packages, so that using this feature would not require custom builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5317) Authorize the agent's '/containers' endpoint
[ https://issues.apache.org/jira/browse/MESOS-5317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15288684#comment-15288684 ] Adam B commented on MESOS-5317: --- [~jieyu] tells me we can do coarse-grained authz on this endpoint for 0.29 and consider filtering in a future release. The only consumers Jie is aware of are superuser-level services/scripts that want the unfiltered contents anyway. > Authorize the agent's '/containers' endpoint > > > Key: MESOS-5317 > URL: https://issues.apache.org/jira/browse/MESOS-5317 > Project: Mesos > Issue Type: Improvement > Components: security, slave >Reporter: Greg Mann >Assignee: Abhishek Dasgupta > Labels: authorization, mesosphere > Fix For: 0.29.0 > > > After the agent's {{/containers}} endpoint is authenticated, we should > enabled authorization as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-5317) Authorize the agent's '/containers' endpoint
[ https://issues.apache.org/jira/browse/MESOS-5317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Dasgupta reassigned MESOS-5317: Assignee: Abhishek Dasgupta > Authorize the agent's '/containers' endpoint > > > Key: MESOS-5317 > URL: https://issues.apache.org/jira/browse/MESOS-5317 > Project: Mesos > Issue Type: Improvement > Components: security, slave >Reporter: Greg Mann >Assignee: Abhishek Dasgupta > Labels: authorization, mesosphere > Fix For: 0.29.0 > > > After the agent's {{/containers}} endpoint is authenticated, we should > enabled authorization as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5169) Introduce new Authorizer Actions for Authorized based filtering of endpoints.
[ https://issues.apache.org/jira/browse/MESOS-5169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15288660#comment-15288660 ] Adam B commented on MESOS-5169: --- cc: [~vinodkone] > Introduce new Authorizer Actions for Authorized based filtering of endpoints. > - > > Key: MESOS-5169 > URL: https://issues.apache.org/jira/browse/MESOS-5169 > Project: Mesos > Issue Type: Improvement > Components: security >Reporter: Joerg Schad >Assignee: Joerg Schad > Labels: authorization, mesosphere, security > Fix For: 0.29.0 > > > For authorization based endpoint filtering we need to introduce the > authorizer actions outlined via MESOS-4932. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5005) Enforce that DiskInfo principal is equal to framework/operator principal
[ https://issues.apache.org/jira/browse/MESOS-5005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15288599#comment-15288599 ] Greg Mann commented on MESOS-5005: -- Reviews here: https://reviews.apache.org/r/47515/ https://reviews.apache.org/r/47528/ https://reviews.apache.org/r/47519/ https://reviews.apache.org/r/47520/ https://reviews.apache.org/r/47521/ https://reviews.apache.org/r/47522/ https://reviews.apache.org/r/47516/ > Enforce that DiskInfo principal is equal to framework/operator principal > > > Key: MESOS-5005 > URL: https://issues.apache.org/jira/browse/MESOS-5005 > Project: Mesos > Issue Type: Bug >Reporter: Greg Mann >Assignee: Greg Mann > Labels: mesosphere, persistent-volumes, reservations > Fix For: 0.29.0 > > > Currently, we require that {{ReservationInfo.principal}} be equal to the > principal provided for authentication, which means that when HTTP > authentication is disabled this field cannot be set. Based on comments in > 'mesos.proto', the original intention was to enforce this same constraint for > {{Persistence.principal}}, but it seems that we don't enforce it. This should > be changed to make the two fields equivalent, with one exception: when the > framework/operator principal is {{None}}, we should allow the principal in > {{DiskInfo}} to take any value, along the same lines as MESOS-5212. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5405) Make fields in authorization::Request protobuf optional.
[ https://issues.apache.org/jira/browse/MESOS-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15288594#comment-15288594 ] Alexander Rukletsov commented on MESOS-5405: I'd rather vote for the original solution for the following reasons: * proto3 does not support required fields, if we want to migrate eventually we will have to get rid of them anyway; * the design is still error-prone: checks you've added do not protect if local authorizer is not used * the code is not concise; we require people to call certain function only in order to please proto rules To overcome the drawback of your first solution, how about you keep fields in {{Subject}} and {{Object}} optional? This way, we can still upgrade to a union styled {{object}} if we would like to. I don't see why this change deeply impacts the design of the authorizer. We are allowed to express {{ANY}}, with the change you proposed, there will be _just_ another way to express it. Basically, we already do it everywhere in the codebase, we just legalize it. Moreover, while absence of a {{subject}} and {{subject}} with absent {{value}} mean the same thing now, we may even want to change it in the future, so this gives us an extra degree of freedom. > Make fields in authorization::Request protobuf optional. > > > Key: MESOS-5405 > URL: https://issues.apache.org/jira/browse/MESOS-5405 > Project: Mesos > Issue Type: Bug >Reporter: Alexander Rukletsov >Assignee: Till Toenshoff >Priority: Blocker > Labels: mesosphere, security > Fix For: 0.29.0 > > > Currently {{authorization::Request}} protobuf declares {{subject}} and > {{object}} as required fields. However, in the codebase we not always set > them, which renders the message in the uninitialized state, for example: > * > https://github.com/apache/mesos/blob/0bfd6999ebb55ddd45e2c8566db17ab49bc1ffec/src/common/http.cpp#L603 > * > https://github.com/apache/mesos/blob/0bfd6999ebb55ddd45e2c8566db17ab49bc1ffec/src/master/http.cpp#L2057 > I believe that the reason why we don't see issues related to this is because > we never send authz requests over the wire, i.e., never serialize/deserialize > them. However, they are still invalid protobuf messages. Moreover, some > external authorizers may serialize these messages. > We can either ensure all required fields are set or make both {{subject}} and > {{object}} fields optional. This will also require updating local authorizer, > which should properly handle the situation when these fields are absent. We > may also want to notify authors of external authorizers to update their code > accordingly. > It looks like no deprecation is necessary, mainly because we > already—erroneously!—treat these fields as optional. -- This message was sent by Atlassian JIRA (v6.3.4#6332)