[jira] [Assigned] (MESOS-5406) Validate ACLs on creating an instance of local authorizer.

[Jay Guo (JIRA)]

 [ 
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

[JIRA]

 [ 
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

[JIRA]

[ 
https://issues.apache.org/jira/browse/MESOS-2578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[JIRA]

 [ 
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

[Deshi Xiao (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Qian Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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=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

[Vinod Kone (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Qian Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (MESOS-5412) Support CNI_ARGS

[Qian Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Artem Harutyunyan (JIRA)]

 [ 
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

[Artem Harutyunyan (JIRA)]

 [ 
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

[Alexander Rukletsov (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-1554) Persistent resources support for storage-like services

[Adam B (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Adam B (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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.

[Gilbert Song (JIRA)]

 [ 
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 (JIRA)]

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-5310) Enable `network/cni` isolator to allow modifications and deletion of CNI config

[Avinash Sridharan (JIRA)]

 [ 
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

[Vinod Kone (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[haosdent (JIRA)]

 [ 
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

[Abhishek Dasgupta (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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.

[Alexander Rukletsov (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Commented] (MESOS-3932) Silence Boost compiler warnings with CMake

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[JIRA]

 [ 
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

[JIRA]

 [ 
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

[JIRA]

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

[Adam B (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Abhishek Dasgupta (JIRA)]

 [ 
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.

[Adam B (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Greg Mann (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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.

[Alexander Rukletsov (JIRA)]

[ 
https://issues.apache.org/jira/browse/MESOS-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[jira] [Updated] (MESOS-2043) framework auth fail with timeout error and never get authenticated

[Adam B (JIRA)]

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

Adam B updated MESOS-2043:
--
Sprint: Mesosphere Sprint 35

> 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
>Assignee: Greg Mann
>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] [Updated] (MESOS-5404) Allow `Task` to be authorized.

[Adam B (JIRA)]

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

Adam B updated MESOS-5404:
--
   Sprint: Mesosphere Sprint 35
Fix Version/s: 0.29.0
  Component/s: security

> Allow `Task` to be authorized.
> --
>
> Key: MESOS-5404
> URL: https://issues.apache.org/jira/browse/MESOS-5404
> Project: Mesos
>  Issue Type: Improvement
>  Components: security
>Reporter: Joerg Schad
>Assignee: Joerg Schad
>  Labels: mesosphere, security
> Fix For: 0.29.0
>
>
> As we need to be able to authorize `Tasks` (e.g., for deciding whether to 
> include them in the /state endpoint when applying authorization based 
> filtering) we need to expose it to the authorizer. Secondly we also need to 
> include some additional information (`user` and `Env variables`) in order to 
> provide the authorizer  with meaning information.



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

[jira] [Updated] (MESOS-5404) Allow `Task` to be authorized.

[Adam B (JIRA)]

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

Adam B updated MESOS-5404:
--
Labels: mesosphere security  (was: )

> Allow `Task` to be authorized.
> --
>
> Key: MESOS-5404
> URL: https://issues.apache.org/jira/browse/MESOS-5404
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Joerg Schad
>Assignee: Joerg Schad
>  Labels: mesosphere, security
>
> As we need to be able to authorize `Tasks` (e.g., for deciding whether to 
> include them in the /state endpoint when applying authorization based 
> filtering) we need to expose it to the authorizer. Secondly we also need to 
> include some additional information (`user` and `Env variables`) in order to 
> provide the authorizer  with meaning information.



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

[jira] [Commented] (MESOS-5404) Allow `Task` to be authorized.

[Adam B (JIRA)]

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

Adam B commented on MESOS-5404:
---

Besides adding more individual fields to Task, another option would be to add 
the entire TaskInfo (or at least CommandInfo) to the Task. But that's probably 
a bit drastic for right now.

> Allow `Task` to be authorized.
> --
>
> Key: MESOS-5404
> URL: https://issues.apache.org/jira/browse/MESOS-5404
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Joerg Schad
>Assignee: Joerg Schad
>
> As we need to be able to authorize `Tasks` (e.g., for deciding whether to 
> include them in the /state endpoint when applying authorization based 
> filtering) we need to expose it to the authorizer. Secondly we also need to 
> include some additional information (`user` and `Env variables`) in order to 
> provide the authorizer  with meaning information.



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