[jira] [Updated] (MESOS-4931) Authorization based filtering for endpoints.

[Vinod Kone (JIRA)]

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

Vinod Kone updated MESOS-4931:
--
Priority: Blocker  (was: Major)

> Authorization based filtering for endpoints.
> 
>
> Key: MESOS-4931
> URL: https://issues.apache.org/jira/browse/MESOS-4931
> Project: Mesos
>  Issue Type: Epic
>  Components: security
>Reporter: Joerg Schad
>Assignee: Joerg Schad
>Priority: Blocker
>  Labels: authorization, mesosphere, security
> Fix For: 1.0.0
>
>
> Some endpoints such as /state should be filtered depending on which 
> information the user is authorized to see. For example a user should be only 
> able to see tasks he is authorized to see.



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

[jira] [Updated] (MESOS-5459) Update RUN_TASK_WITH_USER to use additional metadata

[Vinod Kone (JIRA)]

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

Vinod Kone updated MESOS-5459:
--
Priority: Blocker  (was: Major)

Marking this as a blocker because this is an API change? [~adam-mesos] please 
downgrade if it's not.

> Update RUN_TASK_WITH_USER to use additional metadata
> 
>
> Key: MESOS-5459
> URL: https://issues.apache.org/jira/browse/MESOS-5459
> Project: Mesos
>  Issue Type: Improvement
>  Components: security
>Reporter: Adam B
>Assignee: Benjamin Bannier
>Priority: Blocker
>  Labels: mesosphere, security
> Fix For: 1.0.0
>
>
> Currently, the `authorization::Action` `RUN_TASK_WITH_USER` will pass the 
> user as its `Object.value` string, but some authorizers may want to make 
> authorization decisions based on additional task attributes, like role, 
> resources, labels, container type, etc.
> We should create a new Action `RUN_TASK` that passes FrameworkInfo and 
> TaskInfo in its Object, and the LocalAuthorizer's RunTaskWithUser ACL can be 
> implemented using the user found in TaskInfo/FrameworkInfo.
> We may need to leave the old _WITH_USER action around, but it's arguable 
> whether we should call the authorizer once for RUN_TASK and once for 
> RUN_TASK_WITH_USER, or only use the new action and deprecate the old one?



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

[jira] [Updated] (MESOS-2948) Generalize authorizer interface in order to allow for arbitrary Subjects, Actions and Objects

[Vinod Kone (JIRA)]

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

Vinod Kone updated MESOS-2948:
--
Priority: Blocker  (was: Major)

> Generalize authorizer interface in order to allow for arbitrary Subjects, 
> Actions and Objects
> -
>
> Key: MESOS-2948
> URL: https://issues.apache.org/jira/browse/MESOS-2948
> Project: Mesos
>  Issue Type: Epic
>  Components: master, security
>Reporter: Alexander Rojas
>Assignee: Alexander Rojas
>Priority: Blocker
>  Labels: acl, mesosphere, security
> Fix For: 1.0.0
>
>
> The current 
> [{{mesos::Authorizer}}|https://github.com/apache/mesos/blob/40b596402521be25b93b9ef4edd8f5c727c9d20e/src/authorizer/authorizer.hpp]
>  API has one method for each of the _actions_ supported (Register Framework, 
> Launch Task and Shutdown Framework), and each of these _actions_ themselves 
> define the _objects_ on which they operate.
> Currently, in case a new action needs to be authorized it is necessary to 
> modify the {{mesos::Authorizer}} interface and all its implementations 
> (currently only {{mesos::LocalAuthorizer}}), and add a new nested message to 
> the {{ACL}} message in {{mesos.proto}}.
> An update to the API should allow for new _actions_ and _objects_ to be added 
> without the need to change the {{mesos::Authorizer}} interface while 
> encapsulating implementation details on how the authorization process is 
> performed.



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

[jira] [Updated] (MESOS-4642) Mesos Agent Json API can dump binary data from log files out as invalid JSON

[Vinod Kone (JIRA)]

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

Vinod Kone updated MESOS-4642:
--
Fix Version/s: (was: 1.0.0)

> Mesos Agent Json API can dump binary data from log files out as invalid JSON
> 
>
> Key: MESOS-4642
> URL: https://issues.apache.org/jira/browse/MESOS-4642
> Project: Mesos
>  Issue Type: Bug
>  Components: json api, slave
>Affects Versions: 0.27.0
>Reporter: Steven Schlansker
>Priority: Critical
>
> One of our tasks accidentally started logging binary data to stderr.  This 
> was not intentional and generally should not happen -- however, it causes 
> severe problems with the Mesos Agent "files/read.json" API, since it gladly 
> dumps this binary data out as invalid JSON.
> {code}
> # hexdump -C /path/to/task/stderr | tail
> 0003d1f0  6f 6e 6e 65 63 74 69 6f  6e 0a 4e 45 54 3a 20 31  |onnection.NET: 1|
> 0003d200  20 6f 6e 72 65 61 64 20  45 4e 4f 45 4e 54 20 32  | onread ENOENT 2|
> 0003d210  39 35 34 35 36 20 32 35  31 20 32 39 35 37 30 37  |95456 251 295707|
> 0003d220  0a 01 00 00 00 00 00 00  ac 57 65 64 2c 20 31 30  |.Wed, 10|
> 0003d230  20 55 6e 72 65 63 6f 67  6e 69 7a 65 64 20 69 6e  | Unrecognized in|
> 0003d240  70 75 74 20 68 65 61 64  65 72 0a |put header.|
> {code}
> {code}
> # curl 
> 'http://agent-host:5051/files/read.json?path=/path/to/task/stderr=220443=9='
>  | hexdump -C
> 7970  6e 65 63 74 69 6f 6e 5c  6e 4e 45 54 3a 20 31 20  |nection\nNET: 1 |
> 7980  6f 6e 72 65 61 64 20 45  4e 4f 45 4e 54 20 32 39  |onread ENOENT 29|
> 7990  35 34 35 36 20 32 35 31  20 32 39 35 37 30 37 5c  |5456 251 295707\|
> 79a0  6e 5c 75 30 30 30 31 5c  75 30 30 30 30 5c 75 30  |n\u0001\u\u0|
> 79b0  30 30 30 5c 75 30 30 30  30 5c 75 30 30 30 30 5c  |000\u\u\|
> 79c0  75 30 30 30 30 5c 75 30  30 30 30 ac 57 65 64 2c  |u\u.Wed,|
> 79d0  20 31 30 20 55 6e 72 65  63 6f 67 6e 69 7a 65 64  | 10 Unrecognized|
> 79e0  20 69 6e 70 75 74 20 68  65 61 64 65 72 5c 6e 22  | input header\n"|
> 79f0  2c 22 6f 66 66 73 65 74  22 3a 32 32 30 34 34 33  |,"offset":220443|
> 7a00  7d|}|
> {code}
> This causes downstream sadness:
> {code}
> ERROR [2016-02-10 18:55:12,303] 
> io.dropwizard.jersey.errors.LoggingExceptionMapper: Error handling a request: 
> 0ee749630f8b26f1
> ! com.fasterxml.jackson.core.JsonParseException: Invalid UTF-8 start byte 0xac
> !  at [Source: org.jboss.netty.buffer.ChannelBufferInputStream@6d69ee8; line: 
> 1, column: 31181]
> ! at 
> com.fasterxml.jackson.core.JsonParser._constructError(JsonParser.java:1487) 
> ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.core.base.ParserMinimalBase._reportError(ParserMinimalBase.java:518)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.core.json.UTF8StreamJsonParser._reportInvalidInitial(UTF8StreamJsonParser.java:3339)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.core.json.UTF8StreamJsonParser._reportInvalidChar(UTF8StreamJsonParser.java:)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.core.json.UTF8StreamJsonParser._finishString2(UTF8StreamJsonParser.java:2360)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.core.json.UTF8StreamJsonParser._finishString(UTF8StreamJsonParser.java:2287)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.core.json.UTF8StreamJsonParser.getText(UTF8StreamJsonParser.java:286)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.databind.deser.std.StringDeserializer.deserialize(StringDeserializer.java:29)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.databind.deser.std.StringDeserializer.deserialize(StringDeserializer.java:12)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.databind.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:523)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeUsingPropertyBased(BeanDeserializer.java:381)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.databind.deser.BeanDeserializerBase.deserializeFromObjectUsingNonDefault(BeanDeserializerBase.java:1073)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.module.afterburner.deser.SuperSonicBeanDeserializer.deserializeFromObject(SuperSonicBeanDeserializer.java:196)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:142)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.module.afterburner.deser.SuperSonicBeanDeserializer.deserialize(SuperSonicBeanDeserializer.java:117)
>  

[jira] [Updated] (MESOS-4279) Docker executor truncates task's output when the task is killed.

[Vinod Kone (JIRA)]

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

Vinod Kone updated MESOS-4279:
--
Priority: Critical  (was: Blocker)

Downgrading this to critical because it's not an API change blocking 1.0-RC1. 
Still keeping the fix version because we want to get it in before the 1.0 
official release.

> Docker executor truncates task's output when the task is killed.
> 
>
> Key: MESOS-4279
> URL: https://issues.apache.org/jira/browse/MESOS-4279
> Project: Mesos
>  Issue Type: Bug
>  Components: containerization, docker
>Affects Versions: 0.25.0, 0.26.0, 0.27.2, 0.28.1
>Reporter: Martin Bydzovsky
>Assignee: Martin Bydzovsky
>Priority: Critical
>  Labels: docker, mesosphere
> Fix For: 1.0.0
>
>
> I'm implementing a graceful restarts of our mesos-marathon-docker setup and I 
> came to a following issue:
> (it was already discussed on 
> https://github.com/mesosphere/marathon/issues/2876 and guys form mesosphere 
> got to a point that its probably a docker containerizer problem...)
> To sum it up:
> When i deploy simple python script to all mesos-slaves:
> {code}
> #!/usr/bin/python
> from time import sleep
> import signal
> import sys
> import datetime
> def sigterm_handler(_signo, _stack_frame):
> print "got %i" % _signo
> print datetime.datetime.now().time()
> sys.stdout.flush()
> sleep(2)
> print datetime.datetime.now().time()
> print "ending"
> sys.stdout.flush()
> sys.exit(0)
> signal.signal(signal.SIGTERM, sigterm_handler)
> signal.signal(signal.SIGINT, sigterm_handler)
> try:
> print "Hello"
> i = 0
> while True:
> i += 1
> print datetime.datetime.now().time()
> print "Iteration #%i" % i
> sys.stdout.flush()
> sleep(1)
> finally:
> print "Goodbye"
> {code}
> and I run it through Marathon like
> {code:javascript}
> data = {
>   args: ["/tmp/script.py"],
>   instances: 1,
>   cpus: 0.1,
>   mem: 256,
>   id: "marathon-test-api"
> }
> {code}
> During the app restart I get expected result - the task receives sigterm and 
> dies peacefully (during my script-specified 2 seconds period)
> But when i wrap this python script in a docker:
> {code}
> FROM node:4.2
> RUN mkdir /app
> ADD . /app
> WORKDIR /app
> ENTRYPOINT []
> {code}
> and run appropriate application by Marathon:
> {code:javascript}
> data = {
>   args: ["./script.py"],
>   container: {
>   type: "DOCKER",
>   docker: {
>   image: "bydga/marathon-test-api"
>   },
>   forcePullImage: yes
>   },
>   cpus: 0.1,
>   mem: 256,
>   instances: 1,
>   id: "marathon-test-api"
> }
> {code}
> The task during restart (issued from marathon) dies immediately without 
> having a chance to do any cleanup.



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

[jira] [Updated] (MESOS-5420) Implement os::exists for processes

[Joris Van Remoortere (JIRA)]

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

Joris Van Remoortere updated MESOS-5420:

Sprint: Mesosphere Sprint 36

> Implement os::exists for processes
> --
>
> Key: MESOS-5420
> URL: https://issues.apache.org/jira/browse/MESOS-5420
> Project: Mesos
>  Issue Type: Improvement
> Environment: Windows
>Reporter: Daniel Pravat
>Assignee: Daniel Pravat
>  Labels: mesosphere
> Fix For: 1.0.0
>
>
> os::exists returns true if the process identified by the parameter is still 
> running or was running and we are able to get information about it, such us 
> the exit code. In Windows after obtaining a handle to the process it is 
> possible perform those operations. 



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

[jira] [Updated] (MESOS-3624) Port slave/containerizer/mesos/launch.cpp to Windows

[Joris Van Remoortere (JIRA)]

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

Joris Van Remoortere updated MESOS-3624:

Sprint: Mesosphere Sprint 36

> Port slave/containerizer/mesos/launch.cpp to Windows
> 
>
> Key: MESOS-3624
> URL: https://issues.apache.org/jira/browse/MESOS-3624
> Project: Mesos
>  Issue Type: Task
>  Components: containerization
>Reporter: Alex Clemmer
>Assignee: Alex Clemmer
>  Labels: mesosphere, windows
> Fix For: 1.0.0
>
>
> Important subset of the dependency tree follows:
> slave/containerizer/mesos/launch.cpp: os, protobuf, launch
> launch: subcommand
> subcommand: flags
> flags.hpp: os.hpp, path.hpp, fetch.hpp



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

[jira] [Commented] (MESOS-4642) Mesos Agent Json API can dump binary data from log files out as invalid JSON

[Joseph Wu (JIRA)]

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

Joseph Wu commented on MESOS-4642:
--

Only the new V1 Operator API replacement for the {{/files/read}} endpoint will 
be affected.  We're not making any changes to how we render JSON globally.  But 
the new API won't have the problem described in this JIRA.

> Mesos Agent Json API can dump binary data from log files out as invalid JSON
> 
>
> Key: MESOS-4642
> URL: https://issues.apache.org/jira/browse/MESOS-4642
> Project: Mesos
>  Issue Type: Bug
>  Components: json api, slave
>Affects Versions: 0.27.0
>Reporter: Steven Schlansker
>Priority: Critical
> Fix For: 1.0.0
>
>
> One of our tasks accidentally started logging binary data to stderr.  This 
> was not intentional and generally should not happen -- however, it causes 
> severe problems with the Mesos Agent "files/read.json" API, since it gladly 
> dumps this binary data out as invalid JSON.
> {code}
> # hexdump -C /path/to/task/stderr | tail
> 0003d1f0  6f 6e 6e 65 63 74 69 6f  6e 0a 4e 45 54 3a 20 31  |onnection.NET: 1|
> 0003d200  20 6f 6e 72 65 61 64 20  45 4e 4f 45 4e 54 20 32  | onread ENOENT 2|
> 0003d210  39 35 34 35 36 20 32 35  31 20 32 39 35 37 30 37  |95456 251 295707|
> 0003d220  0a 01 00 00 00 00 00 00  ac 57 65 64 2c 20 31 30  |.Wed, 10|
> 0003d230  20 55 6e 72 65 63 6f 67  6e 69 7a 65 64 20 69 6e  | Unrecognized in|
> 0003d240  70 75 74 20 68 65 61 64  65 72 0a |put header.|
> {code}
> {code}
> # curl 
> 'http://agent-host:5051/files/read.json?path=/path/to/task/stderr=220443=9='
>  | hexdump -C
> 7970  6e 65 63 74 69 6f 6e 5c  6e 4e 45 54 3a 20 31 20  |nection\nNET: 1 |
> 7980  6f 6e 72 65 61 64 20 45  4e 4f 45 4e 54 20 32 39  |onread ENOENT 29|
> 7990  35 34 35 36 20 32 35 31  20 32 39 35 37 30 37 5c  |5456 251 295707\|
> 79a0  6e 5c 75 30 30 30 31 5c  75 30 30 30 30 5c 75 30  |n\u0001\u\u0|
> 79b0  30 30 30 5c 75 30 30 30  30 5c 75 30 30 30 30 5c  |000\u\u\|
> 79c0  75 30 30 30 30 5c 75 30  30 30 30 ac 57 65 64 2c  |u\u.Wed,|
> 79d0  20 31 30 20 55 6e 72 65  63 6f 67 6e 69 7a 65 64  | 10 Unrecognized|
> 79e0  20 69 6e 70 75 74 20 68  65 61 64 65 72 5c 6e 22  | input header\n"|
> 79f0  2c 22 6f 66 66 73 65 74  22 3a 32 32 30 34 34 33  |,"offset":220443|
> 7a00  7d|}|
> {code}
> This causes downstream sadness:
> {code}
> ERROR [2016-02-10 18:55:12,303] 
> io.dropwizard.jersey.errors.LoggingExceptionMapper: Error handling a request: 
> 0ee749630f8b26f1
> ! com.fasterxml.jackson.core.JsonParseException: Invalid UTF-8 start byte 0xac
> !  at [Source: org.jboss.netty.buffer.ChannelBufferInputStream@6d69ee8; line: 
> 1, column: 31181]
> ! at 
> com.fasterxml.jackson.core.JsonParser._constructError(JsonParser.java:1487) 
> ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.core.base.ParserMinimalBase._reportError(ParserMinimalBase.java:518)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.core.json.UTF8StreamJsonParser._reportInvalidInitial(UTF8StreamJsonParser.java:3339)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.core.json.UTF8StreamJsonParser._reportInvalidChar(UTF8StreamJsonParser.java:)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.core.json.UTF8StreamJsonParser._finishString2(UTF8StreamJsonParser.java:2360)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.core.json.UTF8StreamJsonParser._finishString(UTF8StreamJsonParser.java:2287)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.core.json.UTF8StreamJsonParser.getText(UTF8StreamJsonParser.java:286)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.databind.deser.std.StringDeserializer.deserialize(StringDeserializer.java:29)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.databind.deser.std.StringDeserializer.deserialize(StringDeserializer.java:12)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.databind.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:523)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeUsingPropertyBased(BeanDeserializer.java:381)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.databind.deser.BeanDeserializerBase.deserializeFromObjectUsingNonDefault(BeanDeserializerBase.java:1073)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> com.fasterxml.jackson.module.afterburner.deser.SuperSonicBeanDeserializer.deserializeFromObject(SuperSonicBeanDeserializer.java:196)
>  ~[singularity-0.4.9.jar:0.4.9]
> ! at 
> 

[jira] [Created] (MESOS-5522) Add Windows quotes escaping for arguments

[Daniel Pravat (JIRA)]

Daniel Pravat created MESOS-5522:


 Summary: Add Windows quotes escaping for arguments
 Key: MESOS-5522
 URL: https://issues.apache.org/jira/browse/MESOS-5522
 Project: Mesos
  Issue Type: Improvement
Reporter: Daniel Pravat


In Windows, that arguments containing spaces be surrounded by double quotation 
marks. 

https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/everyone-quotes-command-line-arguments-the-wrong-way/



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

[jira] [Commented] (MESOS-3639) Implement stout/os/windows/killtree.hpp

[Joris Van Remoortere (JIRA)]

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

Joris Van Remoortere commented on MESOS-3639:
-

{code}
commit 563c9ff5b539dc2d4ce1ba987dec925045cef5b8
Author: Daniel Pravat 
Date:   Mon May 30 18:02:24 2016 -0700

Windows: Enabled `JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE` on job objects.

Review: https://reviews.apache.org/r/47442/
{code}

> Implement stout/os/windows/killtree.hpp
> ---
>
> Key: MESOS-3639
> URL: https://issues.apache.org/jira/browse/MESOS-3639
> Project: Mesos
>  Issue Type: Task
>  Components: stout
>Reporter: Alex Clemmer
>Assignee: Daniel Pravat
>  Labels: mesosphere, windows
> Fix For: 0.29.0
>
>
> killtree() is implemented using Windows Job Objects. The processes created by 
> the  executor are associated with a job object using `create_job'. killtree() 
> is simply terminating the job object. 
> Helper functions:
> `create_job` function creates a job object whose name is derived from the 
> `pid` and associates the `pid` process with the job object. Every process 
> started by the process which is part of the job object becomes part of the 
> job object. The job name should match the name used in `kill_job`. The jobs 
> should be create with JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE and allow the caller 
> to decide how to handle the returned handle. 
> `kill_job` function assumes the process identified by `pid` is associated 
> with a job object whose name is derive from it. Every process started by the 
> process which is part of the job object becomes part of the job object. 
> Destroying the task will close all such processes.



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

[jira] [Commented] (MESOS-5417) define WSTRINGIFY behaviour on Windows

[Joris Van Remoortere (JIRA)]

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

Joris Van Remoortere commented on MESOS-5417:
-

{code}
commit ad3e161ac19ac32f5493e8b31bdef7b579c87177
Author: Daniel Pravat 
Date:   Mon May 30 17:48:47 2016 -0700

Windows: Added logging for `WSTRINGIFY` calls.

The return codes in Windows are not standardized. The function returns
an empty string and logs a warning.

Review: https://reviews.apache.org/r/47473/
{code}

> define WSTRINGIFY behaviour on Windows
> --
>
> Key: MESOS-5417
> URL: https://issues.apache.org/jira/browse/MESOS-5417
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Daniel Pravat
>Assignee: Daniel Pravat
>Priority: Minor
>  Labels: windows
>
> Identify the proper behaviour of WSTRINGIFY to improve the logging.  



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

[jira] [Commented] (MESOS-5170) Adapt json creation for authorization based endpoint filtering.

[Joerg Schad (JIRA)]

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

Joerg Schad commented on MESOS-5170:


Added authorization based filtering to /state-summary.
https://reviews.apache.org/r/47559/

Used TaskObjectApprover to filter /state endpoint.
https://reviews.apache.org/r/47704/

Used TaskObjectApprover to filter /tasks endpoint.
https://reviews.apache.org/r/47736/

Added tests for VIEW_* authorization actions.
https://reviews.apache.org/r/47977/

> Adapt json creation for authorization based endpoint filtering.
> ---
>
> Key: MESOS-5170
> URL: https://issues.apache.org/jira/browse/MESOS-5170
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Joerg Schad
>Assignee: Joerg Schad
>  Labels: authorization, mesosphere, security
> Fix For: 0.29.0
>
>
> For authorization based endpoint filtering we need to adapt the json endpoint 
> creation as discussed in MESOS-4931.



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

[jira] [Updated] (MESOS-5403) Introduce ObjectApprover Interface to Authorizer.

[Joerg Schad (JIRA)]

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

Joerg Schad updated MESOS-5403:
---
Summary: Introduce ObjectApprover Interface to Authorizer.  (was: Introduce 
ObjectFilter Interface to Authorizer.)

> Introduce ObjectApprover Interface to Authorizer.
> -
>
> Key: MESOS-5403
> URL: https://issues.apache.org/jira/browse/MESOS-5403
> Project: Mesos
>  Issue Type: Bug
>Reporter: Joerg Schad
>Assignee: Joerg Schad
>
> As outlined here 
> (https://docs.google.com/document/d/1FuS79P8uj5PIBycrBlkJSBKOtmeO8ezAuiNXxwIA3qA)
>  we plan to add the option of retrieving a FilterObject from the Authorizer 
> with the goal of allowing for efficient authorization of a large number of 
> (potentially large) objects. 



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

[jira] [Commented] (MESOS-5405) Make fields in authorization::Request protobuf optional.

[Alexander Rojas (JIRA)]

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

Alexander Rojas commented on MESOS-5405:


Well, I share Adam's opinion. Not to mention that one of the purposes of the 
design was to make the calling logic somewhat friendlier and easier to track 
and going for the second approach doesn't achieve that goal.

> 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-5179) Enhance the error message for Duration flag.

[Alexander Rukletsov (JIRA)]

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

Alexander Rukletsov updated MESOS-5179:
---
  Sprint: Mesosphere Sprint 36
Story Points: 1  (was: 3)
  Labels: mesosphere  (was: )

> Enhance the error message for Duration flag.
> 
>
> Key: MESOS-5179
> URL: https://issues.apache.org/jira/browse/MESOS-5179
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Guangya Liu
>Assignee: Guangya Liu
>Priority: Minor
>  Labels: mesosphere
>
> Enhance the error message for  
> https://github.com/apache/mesos/blob/4dfa91fc21f80204f5125b2e2f35c489f8fb41d8/3rdparty/libprocess/3rdparty/stout/include/stout/duration.hpp#L70
>  to list all of the supported duration unit.



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

[jira] [Commented] (MESOS-2717) Qemu/KVM containerizer

[Jie Yu (JIRA)]

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

Jie Yu commented on MESOS-2717:
---

Instead of introducing a new containerizer, I would prefer the implementation 
to be part of Mesos containerizer, although that might involve some major 
refactor of the existing Mesos containerizer, but I think that's the right way 
to go. We already feel the pain of maintaining two containerizers (Mesos and 
Docker containerizers). Every time we introduce a new feature (e.g., persistent 
volume, gpu, etc.), we need to provide two implementations for both 
containerizers. If we introduce yet another containerizer, this will soon 
become impossible.

> Qemu/KVM containerizer
> --
>
> Key: MESOS-2717
> URL: https://issues.apache.org/jira/browse/MESOS-2717
> Project: Mesos
>  Issue Type: Wish
>  Components: containerization
>Reporter: Pierre-Yves Ritschard
>Assignee: Abhishek Dasgupta
>
> I think it would make sense for Mesos to have the ability to treat 
> hypervisors as containerizers and the most sensible one to start with would 
> probably be Qemu/KVM.
> There are a few workloads that can require full-fledged VMs (the most obvious 
> one being Windows workloads).
> The containerization code is well decoupled and seems simple enough, I can 
> definitely take a shot at it. VMs do bring some questions with them here is 
> my take on them:
> 1. Routing, network strategy
> ==
> The simplest approach here might very well be to go for bridged networks
> and leave the setup and inter slave routing up to the administrator
> 2. IP Address assignment
> 
> At first, it can be up to the Frameworks to deal with IP assignment.
> The simplest way to address this could be to have an executor running
> on slaves providing the qemu/kvm containerizer which would instrument a DHCP 
> server and collect IP + Mac address resources from slaves. While it may be up 
> to the frameworks to provide this, an example should most likely be provided.
> 3. VM Templates
> ==
> VM templates should probably leverage the fetcher and could thus be copied 
> locally or fetch from HTTP(s) / HDFS.
> 4. Resource limiting
> 
> Mapping resouce constraints to the qemu command line is probably the easiest 
> part, Additional command line should also be fetchable. For Unix VMs, the 
> sandbox could show the output of the serial console
> 5. Libvirt / plain Qemu
> =
> I tend to favor limiting the amount of necessary hoops to jump through and 
> would thus investigate working directly with Qemu, maintaining an open 
> connection to the monitor to assert status.



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

[jira] [Updated] (MESOS-5521) Refresh Mesos project website adopters page

[Tomasz Janiszewski (JIRA)]

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

Tomasz Janiszewski updated MESOS-5521:
--
Assignee: (was: Tomasz Janiszewski)

> Refresh Mesos project website adopters page
> ---
>
> Key: MESOS-5521
> URL: https://issues.apache.org/jira/browse/MESOS-5521
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Tomasz Janiszewski
>Priority: Minor
> Attachments: mobile.png, pc.png, tablet.png
>
>




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

[jira] [Updated] (MESOS-5521) Refresh Mesos project website adopters page

[Tomasz Janiszewski (JIRA)]

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

Tomasz Janiszewski updated MESOS-5521:
--
Attachment: pc.png

> Refresh Mesos project website adopters page
> ---
>
> Key: MESOS-5521
> URL: https://issues.apache.org/jira/browse/MESOS-5521
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Tomasz Janiszewski
>Assignee: Tomasz Janiszewski
>Priority: Minor
> Attachments: mobile.png, pc.png, tablet.png
>
>




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

[jira] [Updated] (MESOS-5521) Refresh Mesos project website adopters page

[Tomasz Janiszewski (JIRA)]

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

Tomasz Janiszewski updated MESOS-5521:
--
Attachment: (was: pc)

> Refresh Mesos project website adopters page
> ---
>
> Key: MESOS-5521
> URL: https://issues.apache.org/jira/browse/MESOS-5521
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Tomasz Janiszewski
>Assignee: Tomasz Janiszewski
>Priority: Minor
> Attachments: mobile.png, tablet.png
>
>




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

[jira] [Updated] (MESOS-5521) Refresh Mesos project website adopters page

[Tomasz Janiszewski (JIRA)]

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

Tomasz Janiszewski updated MESOS-5521:
--
Attachment: mobile.png
tablet.png
pc

> Refresh Mesos project website adopters page
> ---
>
> Key: MESOS-5521
> URL: https://issues.apache.org/jira/browse/MESOS-5521
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Tomasz Janiszewski
>Assignee: Tomasz Janiszewski
>Priority: Minor
> Attachments: mobile.png, pc, tablet.png
>
>




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

[jira] [Updated] (MESOS-5521) Refresh Mesos project website adopters page

[Tomasz Janiszewski (JIRA)]

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

Tomasz Janiszewski updated MESOS-5521:
--
Priority: Minor  (was: Major)

> Refresh Mesos project website adopters page
> ---
>
> Key: MESOS-5521
> URL: https://issues.apache.org/jira/browse/MESOS-5521
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Tomasz Janiszewski
>Assignee: Tomasz Janiszewski
>Priority: Minor
>




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

[jira] [Assigned] (MESOS-5521) Refresh Mesos project website adopters page

[Tomasz Janiszewski (JIRA)]

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

Tomasz Janiszewski reassigned MESOS-5521:
-

Assignee: Tomasz Janiszewski  (was: haosdent)

> Refresh Mesos project website adopters page
> ---
>
> Key: MESOS-5521
> URL: https://issues.apache.org/jira/browse/MESOS-5521
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Tomasz Janiszewski
>Assignee: Tomasz Janiszewski
>




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

[jira] [Created] (MESOS-5521) Refresh Mesos project website adopters page

[Tomasz Janiszewski (JIRA)]

Tomasz Janiszewski created MESOS-5521:
-

 Summary: Refresh Mesos project website adopters page
 Key: MESOS-5521
 URL: https://issues.apache.org/jira/browse/MESOS-5521
 Project: Mesos
  Issue Type: Improvement
Reporter: Tomasz Janiszewski
Assignee: haosdent






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

[jira] [Comment Edited] (MESOS-4512) Render quota status consistently with other endpoints.

[Alexander Rukletsov (JIRA)]

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

Alexander Rukletsov edited comment on MESOS-4512 at 5/30/16 8:29 PM:
-

I meant the role in {{Resource}}, not the one on {{QuotaInfo}}. Printing '\*' 
there is misleading, because the resource is set aside for quota, but since 
technically it is not a reserved resource, {{Resource.role}} must be '\*'. 

Since we are deprecating {{model()}} functions, we can't really do better here 
and will have to print {{Resource}} proto. I'm fine with closing the ticket.


was (Author: alexr):
I meant the role in {{Resource}}, not the one on {{QuotaInfo}}. Printing '*' 
there is misleading, because the resource is set aside for quota, but since 
technically it is not a reserved resource, {{Resource.role}} must be '*'. 

Since we are deprecating {{model()}} functions, we can't really do better here 
and will have to print {{Resource}} proto. I'm fine with closing the ticket.

> Render quota status consistently with other endpoints.
> --
>
> Key: MESOS-4512
> URL: https://issues.apache.org/jira/browse/MESOS-4512
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Reporter: Alexander Rukletsov
>Assignee: Alexander Rukletsov
>  Labels: http, mesosphere
>
> Currently quota status endpoint returns a collection of {{QuotaInfo}} protos 
> converted to JSON. An example response looks like this:
> {code:xml}
> {
>   "infos": [
> {
>   "role": "role1",
>   "guarantee": [
> {
>   "name": "cpus",
>   "role": "*",
>   "type": "SCALAR",
>   "scalar": { "value": 12 }
> },
> {
>   "name": "mem",
>   "role": "*",
>   "type": "SCALAR",
>   "scalar": { "value": 6144 }
> }
>   ]
> }
>   ]
> }
> {code}
> Presence of some fields, e.g. "role", is misleading. To address this issue 
> and make the output more informative, we should probably introduce a  
> {{model()}} function for {{QuotaStatus}}.



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

[jira] [Commented] (MESOS-4512) Render quota status consistently with other endpoints.

[Alexander Rukletsov (JIRA)]

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

Alexander Rukletsov commented on MESOS-4512:


I meant the role in {{Resource}}, not the one on {{QuotaInfo}}. Printing '*' 
there is misleading, because the resource is set aside for quota, but since 
technically it is not a reserved resource, {{Resource.role}} must be '*'. 

Since we are deprecating {{model()}} functions, we can't really do better here 
and will have to print {{Resource}} proto. I'm fine with closing the ticket.

> Render quota status consistently with other endpoints.
> --
>
> Key: MESOS-4512
> URL: https://issues.apache.org/jira/browse/MESOS-4512
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Reporter: Alexander Rukletsov
>Assignee: Alexander Rukletsov
>  Labels: http, mesosphere
>
> Currently quota status endpoint returns a collection of {{QuotaInfo}} protos 
> converted to JSON. An example response looks like this:
> {code:xml}
> {
>   "infos": [
> {
>   "role": "role1",
>   "guarantee": [
> {
>   "name": "cpus",
>   "role": "*",
>   "type": "SCALAR",
>   "scalar": { "value": 12 }
> },
> {
>   "name": "mem",
>   "role": "*",
>   "type": "SCALAR",
>   "scalar": { "value": 6144 }
> }
>   ]
> }
>   ]
> }
> {code}
> Presence of some fields, e.g. "role", is misleading. To address this issue 
> and make the output more informative, we should probably introduce a  
> {{model()}} function for {{QuotaStatus}}.



--
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=15306930#comment-15306930
 ] 

Alexander Rukletsov commented on MESOS-5405:


cc [~arojas]

> 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] [Commented] (MESOS-4909) Introduce kill policy for tasks.

[Alexander Rukletsov (JIRA)]

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

Alexander Rukletsov commented on MESOS-4909:


0.29 will be cut in the next week and released in approx. a month from now. 
Until then, can you confirm that this ticket resolves your issue? You may build 
Mesos from sources if your issue is easily reproducible. Also, feel free to 
file a bug ticket to track it properly.

> Introduce kill policy for tasks.
> 
>
> Key: MESOS-4909
> URL: https://issues.apache.org/jira/browse/MESOS-4909
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Alexander Rukletsov
>Assignee: Alexander Rukletsov
>  Labels: mesosphere
> Fix For: 0.29.0
>
>
> A task may require some time to clean up or even a special mechanism to issue 
> a kill request (currently it's a SIGTERM followed by SIGKILL). Introducing 
> kill policies per task will help address these issue.



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

[jira] [Updated] (MESOS-5497) Implement GET_LEADING_MASTER Call in v1 master API.

[Anand Mazumdar (JIRA)]

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

Anand Mazumdar updated MESOS-5497:
--
Shepherd: Vinod Kone

> Implement GET_LEADING_MASTER Call in v1 master API.
> ---
>
> Key: MESOS-5497
> URL: https://issues.apache.org/jira/browse/MESOS-5497
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Commented] (MESOS-5497) Implement GET_LEADING_MASTER Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta commented on MESOS-5497:
--

RR: https://reviews.apache.org/r/48049/

Also made a minor change in the test case for GET_LOGGING_LEVEL. Was getting 
error if the change was not there. If that change is not needed, we can remove 
it.

> Implement GET_LEADING_MASTER Call in v1 master API.
> ---
>
> Key: MESOS-5497
> URL: https://issues.apache.org/jira/browse/MESOS-5497
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Commented] (MESOS-5493) Implement GET_TASKS Call in v1 master API.

[Jay Guo (JIRA)]

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

Jay Guo commented on MESOS-5493:


RR: https://reviews.apache.org/r/48046/

Need some comments on how to refactor out {{jsonify}} and parse it back to 
JSON::Object, and further into Response message.

> Implement GET_TASKS Call in v1 master API.
> --
>
> Key: MESOS-5493
> URL: https://issues.apache.org/jira/browse/MESOS-5493
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Jay Guo
>




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

[jira] [Commented] (MESOS-3067) Implement a streaming response decoder for events stream

[Anand Mazumdar (JIRA)]

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

Anand Mazumdar commented on MESOS-3067:
---

+1 to what Vinod said.

Also, there have been other suggested alternatives like using 
{{Content-Encoding}} and setting it to {{RecordIO}}. I don't quite like that 
idea since {{RecordIO}} is an _application_ level detail and not how the 
content was actually encoded over the wire as {{Content-Encoding}} seems to 
suggest. 

Since this JIRA is already resolved, I would encourage having this discussion 
on MESOS-3601 that caters explicitly to formalizing such headers.

> Implement a streaming response decoder for events stream
> 
>
> Key: MESOS-3067
> URL: https://issues.apache.org/jira/browse/MESOS-3067
> Project: Mesos
>  Issue Type: Task
>Reporter: Anand Mazumdar
>Assignee: Benjamin Mahler
> Fix For: 0.24.0
>
>
> We need a streaming response decoder to de-serialize chunks sent from the 
> master on the events stream.
> From the HTTP API design doc:
> Master encodes each Event in RecordIO format, i.e. a string representation of 
> length of the event in bytes followed by JSON or binary Protobuf  (possibly 
> compressed) encoded event.
> As of now for getting the basic features right , this is being done in the 
> test-cases:
> {code}
>   auto reader = response.get().reader;
>   ASSERT_SOME(reader);
>   Future eventFuture = reader.get().read();
>   AWAIT_READY(eventFuture);
>   Event event;
>   event.ParseFromString(eventFuture.get());
> {code}
> Two things need to happen:
> - We need master to emit events in RecordIO format i.e. event size followed 
> by the serialized event instead of just the serialized events as is the case 
> now.
> - The decoder class should then abstract away the logic of reading the 
> response and de-serializing events from the stream.
> Ideally, the decoder should work with both "json" and "protobuf" responses.



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

[jira] [Commented] (MESOS-5496) Implement UPDATE_WEIGHTS Call in v1 master API.

[Anand Mazumdar (JIRA)]

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

Anand Mazumdar commented on MESOS-5496:
---

[~dongdong] The {{Response}} protobuf message is different than the {{struct 
Response}} type in libprocess. We currently don't have a generic {{Error}} type 
for representing errors in our protobuf's.  (MESOS-5363)

For now, just invoke: {{return BadRequest("Some Error")}}, {{return 
Forbidden()}} etc similar to other examples in {{src/master/http.cpp}}

> Implement UPDATE_WEIGHTS Call in v1 master API.
> ---
>
> Key: MESOS-5496
> URL: https://issues.apache.org/jira/browse/MESOS-5496
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: zhou xing
>




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

[jira] [Commented] (MESOS-5482) mesos/marathon task stuck in staging after slave reboot

[lutful karim (JIRA)]

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

lutful karim commented on MESOS-5482:
-

[~dma1982]

> mesos/marathon task stuck in staging after slave reboot
> ---
>
> Key: MESOS-5482
> URL: https://issues.apache.org/jira/browse/MESOS-5482
> Project: Mesos
>  Issue Type: Bug
>Reporter: lutful karim
> Attachments: marathon-mesos-masters_after-reboot.log, 
> mesos-masters_mesos.log, mesos_slaves_after_reboot.log, 
> tasks_running_before_rebooot.marathon
>
>
> The main idea of mesos/marathon is to sleep well, but after node reboot mesos 
> task gets stuck in staging for about 4 hours.
> To reproduce the issue: 
> - setup a mesos cluster in HA mode with systemd enabled mesos-master and 
> mesos-slave service.
> - run docker registry (https://hub.docker.com/_/registry/ ) with mesos 
> constraint (hostname:LIKE:mesos-slave-1) in one node. Reboot the node and 
> notice that task getting stuck in staging.
> Possible workaround: service mesos-slave restart fixes the issue.
> OS: centos 7.2
> mesos version: 0.28.1
> marathon: 1.1.1
> zookeeper: 3.4.8
> docker: 1.9.1 dockerAPIversion: 1.21
> error message:
> May 30 08:38:24 euca-10-254-237-140 mesos-slave[832]: W0530 08:38:24.120013   
> 909 slave.cpp:2018] Ignoring kill task 
> docker-registry.066fb448-2628-11e6-bedd-d00d0ef81dc3 because the executor 
> 'docker-registry.066fb448-2628-11e6-bedd-d00d0ef81dc3' of framework 
> 8517fcb7-f2d0-47ad-ae02-837570bef929- is terminating/terminated



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

[jira] [Commented] (MESOS-5496) Implement UPDATE_WEIGHTS Call in v1 master API.

[zhou xing (JIRA)]

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

zhou xing commented on MESOS-5496:
--

[~vinodkone], the old update_weights endpoint can return 3 kinds of http 
response: OK, Forbidden and BadRequest. For v1 API, I did not see the support 
of those different response code in v1::response, do we need to implement them 
first or can we just re-use the traditional HTTP response?

> Implement UPDATE_WEIGHTS Call in v1 master API.
> ---
>
> Key: MESOS-5496
> URL: https://issues.apache.org/jira/browse/MESOS-5496
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: zhou xing
>




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

[jira] [Updated] (MESOS-5482) mesos/marathon task stuck in staging after slave reboot

[lutful karim (JIRA)]

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

lutful karim updated MESOS-5482:

Summary: mesos/marathon task stuck in staging after slave reboot  (was: 
mesos task stuck in staging after slave reboot)

> mesos/marathon task stuck in staging after slave reboot
> ---
>
> Key: MESOS-5482
> URL: https://issues.apache.org/jira/browse/MESOS-5482
> Project: Mesos
>  Issue Type: Bug
>Reporter: lutful karim
> Attachments: marathon-mesos-masters_after-reboot.log, 
> mesos-masters_mesos.log, mesos_slaves_after_reboot.log, 
> tasks_running_before_rebooot.marathon
>
>
> The main idea of mesos/marathon is to sleep well, but after node reboot mesos 
> task gets stuck in staging for about 4 hours.
> To reproduce the issue: 
> - setup a mesos cluster in HA mode with systemd enabled mesos-master and 
> mesos-slave service.
> - run docker registry (https://hub.docker.com/_/registry/ ) with mesos 
> constraint (hostname:LIKE:mesos-slave-1) in one node. Reboot the node and 
> notice that task getting stuck in staging.
> Possible workaround: service mesos-slave restart fixes the issue.
> OS: centos 7.2
> mesos version: 0.28.1
> marathon: 1.1.1
> zookeeper: 3.4.8
> docker: 1.9.1 dockerAPIversion: 1.21
> error message:
> May 30 08:38:24 euca-10-254-237-140 mesos-slave[832]: W0530 08:38:24.120013   
> 909 slave.cpp:2018] Ignoring kill task 
> docker-registry.066fb448-2628-11e6-bedd-d00d0ef81dc3 because the executor 
> 'docker-registry.066fb448-2628-11e6-bedd-d00d0ef81dc3' of framework 
> 8517fcb7-f2d0-47ad-ae02-837570bef929- is terminating/terminated



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

[jira] [Updated] (MESOS-5482) mesos task stuck in staging after slave reboot

[lutful karim (JIRA)]

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

lutful karim updated MESOS-5482:

Attachment: (was: tasks_stuck_after_rebooot.marathon)

> mesos task stuck in staging after slave reboot
> --
>
> Key: MESOS-5482
> URL: https://issues.apache.org/jira/browse/MESOS-5482
> Project: Mesos
>  Issue Type: Bug
>Reporter: lutful karim
> Attachments: marathon-mesos-masters_after-reboot.log, 
> mesos-masters_mesos.log, mesos_slaves_after_reboot.log, 
> tasks_running_before_rebooot.marathon
>
>
> The main idea of mesos/marathon is to sleep well, but after node reboot mesos 
> task gets stuck in staging for about 4 hours.
> To reproduce the issue: 
> - setup a mesos cluster in HA mode with systemd enabled mesos-master and 
> mesos-slave service.
> - run docker registry (https://hub.docker.com/_/registry/ ) with mesos 
> constraint (hostname:LIKE:mesos-slave-1) in one node. Reboot the node and 
> notice that task getting stuck in staging.
> Possible workaround: service mesos-slave restart fixes the issue.
> OS: centos 7.2
> mesos version: 0.28.1
> marathon: 1.1.1
> zookeeper: 3.4.8
> docker: 1.9.1 dockerAPIversion: 1.21
> error message:
> May 30 08:38:24 euca-10-254-237-140 mesos-slave[832]: W0530 08:38:24.120013   
> 909 slave.cpp:2018] Ignoring kill task 
> docker-registry.066fb448-2628-11e6-bedd-d00d0ef81dc3 because the executor 
> 'docker-registry.066fb448-2628-11e6-bedd-d00d0ef81dc3' of framework 
> 8517fcb7-f2d0-47ad-ae02-837570bef929- is terminating/terminated



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

[jira] [Updated] (MESOS-5482) mesos task stuck in staging after slave reboot

[lutful karim (JIRA)]

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

lutful karim updated MESOS-5482:

Attachment: tasks_stuck_after_rebooot.marathon

> mesos task stuck in staging after slave reboot
> --
>
> Key: MESOS-5482
> URL: https://issues.apache.org/jira/browse/MESOS-5482
> Project: Mesos
>  Issue Type: Bug
>Reporter: lutful karim
> Attachments: marathon-mesos-masters_after-reboot.log, 
> mesos-masters_mesos.log, mesos_slaves_after_reboot.log, 
> tasks_running_before_rebooot.marathon, tasks_stuck_after_rebooot.marathon
>
>
> The main idea of mesos/marathon is to sleep well, but after node reboot mesos 
> task gets stuck in staging for about 4 hours.
> To reproduce the issue: 
> - setup a mesos cluster in HA mode with systemd enabled mesos-master and 
> mesos-slave service.
> - run docker registry (https://hub.docker.com/_/registry/ ) with mesos 
> constraint (hostname:LIKE:mesos-slave-1) in one node. Reboot the node and 
> notice that task getting stuck in staging.
> Possible workaround: service mesos-slave restart fixes the issue.
> OS: centos 7.2
> mesos version: 0.28.1
> marathon: 1.1.1
> zookeeper: 3.4.8
> docker: 1.9.1 dockerAPIversion: 1.21
> error message:
> May 30 08:38:24 euca-10-254-237-140 mesos-slave[832]: W0530 08:38:24.120013   
> 909 slave.cpp:2018] Ignoring kill task 
> docker-registry.066fb448-2628-11e6-bedd-d00d0ef81dc3 because the executor 
> 'docker-registry.066fb448-2628-11e6-bedd-d00d0ef81dc3' of framework 
> 8517fcb7-f2d0-47ad-ae02-837570bef929- is terminating/terminated



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

[jira] [Updated] (MESOS-5482) mesos task stuck in staging after slave reboot

[lutful karim (JIRA)]

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

lutful karim updated MESOS-5482:

Description: 
The main idea of mesos/marathon is to sleep well, but after node reboot mesos 
task gets stuck in staging for about 4 hours.

To reproduce the issue: 
- setup a mesos cluster in HA mode with systemd enabled mesos-master and 
mesos-slave service.
- run docker registry (https://hub.docker.com/_/registry/ ) with mesos 
constraint (hostname:LIKE:mesos-slave-1) in one node. Reboot the node and 
notice that task getting stuck in staging.

Possible workaround: service mesos-slave restart fixes the issue.
OS: centos 7.2
mesos version: 0.28.1
marathon: 1.1.1
zookeeper: 3.4.8
docker: 1.9.1 dockerAPIversion: 1.21

error message:
May 30 08:38:24 euca-10-254-237-140 mesos-slave[832]: W0530 08:38:24.120013   
909 slave.cpp:2018] Ignoring kill task 
docker-registry.066fb448-2628-11e6-bedd-d00d0ef81dc3 because the executor 
'docker-registry.066fb448-2628-11e6-bedd-d00d0ef81dc3' of framework 
8517fcb7-f2d0-47ad-ae02-837570bef929- is terminating/terminated


  was:
The main idea of mesos/marathon is to sleep well, but after node reboot mesos 
task gets stuck in staging for about 4 hours.

To reproduce the issue: 
- setup a mesos cluster in HA mode with systemd enabled mesos-master and 
mesos-slave service.
- run docker registry (https://hub.docker.com/_/registry/ ) with mesos 
constraint (hostname:LIKE:mesos-slave-1) in one node. Reboot the node and 
notice that task getting stuck in staging.

Possible workaround: service mesos-slave restart fixes the issue.
OS: centos 7.2
mesos version: 0.28.1
marathon: 1.1.1
zookeeper: 3.4.8
docker: 1.9.1 dockerAPIversion: 1.21



> mesos task stuck in staging after slave reboot
> --
>
> Key: MESOS-5482
> URL: https://issues.apache.org/jira/browse/MESOS-5482
> Project: Mesos
>  Issue Type: Bug
>Reporter: lutful karim
> Attachments: marathon-mesos-masters_after-reboot.log, 
> mesos-masters_mesos.log, mesos_slaves_after_reboot.log, 
> tasks_running_before_rebooot.marathon
>
>
> The main idea of mesos/marathon is to sleep well, but after node reboot mesos 
> task gets stuck in staging for about 4 hours.
> To reproduce the issue: 
> - setup a mesos cluster in HA mode with systemd enabled mesos-master and 
> mesos-slave service.
> - run docker registry (https://hub.docker.com/_/registry/ ) with mesos 
> constraint (hostname:LIKE:mesos-slave-1) in one node. Reboot the node and 
> notice that task getting stuck in staging.
> Possible workaround: service mesos-slave restart fixes the issue.
> OS: centos 7.2
> mesos version: 0.28.1
> marathon: 1.1.1
> zookeeper: 3.4.8
> docker: 1.9.1 dockerAPIversion: 1.21
> error message:
> May 30 08:38:24 euca-10-254-237-140 mesos-slave[832]: W0530 08:38:24.120013   
> 909 slave.cpp:2018] Ignoring kill task 
> docker-registry.066fb448-2628-11e6-bedd-d00d0ef81dc3 because the executor 
> 'docker-registry.066fb448-2628-11e6-bedd-d00d0ef81dc3' of framework 
> 8517fcb7-f2d0-47ad-ae02-837570bef929- is terminating/terminated



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

[jira] [Updated] (MESOS-5482) mesos task stuck in staging after slave reboot

[lutful karim (JIRA)]

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

lutful karim updated MESOS-5482:

Attachment: tasks_running_before_rebooot.marathon
mesos-masters_mesos.log
mesos_slaves_after_reboot.log
marathon-mesos-masters_after-reboot.log

Hi, Please find attached the logs. The task is stuck with following errors:

May 30 08:38:24 euca-10-254-237-140 mesos-slave[832]: I0530 08:38:24.119983   
909 slave.cpp:1891] Asked to kill task 
docker-registry.066fb448-2628-11e6-bedd-d00d0ef81dc3 of framework 
8517fcb7-f2d0-47ad-ae02-837570bef929-
May 30 08:38:24 euca-10-254-237-140 mesos-slave[832]: W0530 08:38:24.120013   
909 slave.cpp:2018] Ignoring kill task 
docker-registry.066fb448-2628-11e6-bedd-d00d0ef81dc3 because the executor 
'docker-registry.066fb448-2628-11e6-bedd-d00d0ef81dc3' of framework 
8517fcb7-f2d0-47ad-ae02-837570bef929- is terminating/terminated
May 30 08:38:24 euca-10-254-237-140 mesos-slave[832]: I0530 08:38:24.120048   
909 slave.cpp:1891] Asked to kill task 
chronos.066f6627-2628-11e6-bedd-d00d0ef81dc3 of framework 
8517fcb7-f2d0-47ad-ae02-837570bef929-
May 30 08:38:24 euca-10-254-237-140 mesos-slave[832]: W0530 08:38:24.120053   
909 slave.cpp:2018] Ignoring kill task 
chronos.066f6627-2628-11e6-bedd-d00d0ef81dc3 because the executor 
'chronos.066f6627-2628-11e6-bedd-d00d0ef81dc3' of framework 
8517fcb7-f2d0-47ad-ae02-837570bef929- is terminating/terminated
May 30 08:38:29 euca-10-254-237-140 mesos-slave[832]: I0530 08:38:29.119302   
909 slave.cpp:1891] Asked to kill task 
docker-registry.066fb448-2628-11e6-bedd-d00d0ef81dc3 of framework 
8517fcb7-f2d0-47ad-ae02-837570bef929-

> mesos task stuck in staging after slave reboot
> --
>
> Key: MESOS-5482
> URL: https://issues.apache.org/jira/browse/MESOS-5482
> Project: Mesos
>  Issue Type: Bug
>Reporter: lutful karim
> Attachments: marathon-mesos-masters_after-reboot.log, 
> mesos-masters_mesos.log, mesos_slaves_after_reboot.log, 
> tasks_running_before_rebooot.marathon
>
>
> The main idea of mesos/marathon is to sleep well, but after node reboot mesos 
> task gets stuck in staging for about 4 hours.
> To reproduce the issue: 
> - setup a mesos cluster in HA mode with systemd enabled mesos-master and 
> mesos-slave service.
> - run docker registry (https://hub.docker.com/_/registry/ ) with mesos 
> constraint (hostname:LIKE:mesos-slave-1) in one node. Reboot the node and 
> notice that task getting stuck in staging.
> Possible workaround: service mesos-slave restart fixes the issue.
> OS: centos 7.2
> mesos version: 0.28.1
> marathon: 1.1.1
> zookeeper: 3.4.8
> docker: 1.9.1 dockerAPIversion: 1.21



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

[jira] [Commented] (MESOS-5153) Sandboxes contents should be protected from unauthorized users

[Adam B (JIRA)]

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

Adam B commented on MESOS-5153:
---

commit 8443b18489c48996df0a88f90baf260a0fb12176
Author: Alexander Rojas 
Date:   Sun May 29 11:16:03 2016 -0700

Enabled authorization for Mesos log access.

Uses the authorization primitives in `mesos::internal::Files` to add
protection of the Mesos logs on both master and agents.

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

All that's left now is the DOCS!

> Sandboxes contents should be protected from unauthorized users
> --
>
> Key: MESOS-5153
> URL: https://issues.apache.org/jira/browse/MESOS-5153
> Project: Mesos
>  Issue Type: Bug
>  Components: security, slave
>Reporter: Alexander Rojas
>Assignee: Alexander Rojas
>  Labels: mesosphere, security
> Fix For: 0.29.0
>
>
> MESOS-4956 introduced authentication support for the sandboxes. However, 
> authentication can only go as far as to tell whether an user is known to 
> mesos or not. An extra additional step is necessary to verify whether the 
> known user is allowed to executed the requested operation on the sandbox 
> (browse, read, download, debug).



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

[jira] [Issue Comment Deleted] (MESOS-5520) Before starting a build, bootstrapping shows some warning

[Ankur Verma (JIRA)]

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

Ankur Verma updated MESOS-5520:
---
Comment: was deleted

(was: automake: this behaviour will change in future Automake versions: they 
will
automake: unconditionally cause object files to be placed in the same 
subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
3rdparty/Makefile.am: installing './depcomp'
3rdparty/Makefile.am:150: warning: variable 'GLOG_LDFLAGS' is defined but no 
program or
3rdparty/Makefile.am:150: library has 'GLOG' as canonical name (possible typo)
3rdparty/libprocess/Makefile.am:95: warning: source file 
'src/authenticator_manager.cpp' is in a subdirectory,
3rdparty/libprocess/Makefile.am:95: but option 'subdir-objects' is disabled
3rdparty/libprocess/Makefile.am:95: warning: source file 
'src/authenticator.cpp' is in a subdirectory,
3rdparty/libprocess/Makefile.am:95: but option 'subdir-objects' is disabled
3rdparty/libprocess/Makefile.am:95: warning: source file 'src/clock.cpp' is in 
a subdirectory,
3rdparty/libprocess/Makefile.am:95: but option 'subdir-objects' is disabled
3rdparty/libprocess/Makefile.am:95: warning: source file 'src/firewall.cpp' is 
in a subdirectory,)

> Before starting a build, bootstrapping shows some warning
> -
>
> Key: MESOS-5520
> URL: https://issues.apache.org/jira/browse/MESOS-5520
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Affects Versions: 0.28.1
> Environment: ubuntu 14.04.4
>Reporter: Ankur Verma
>Priority: Minor
> Attachments: bootstrap_cmd_logs.txt
>
>
> For the first time before building, some warning comes when using command 
> bootstrap
> # Bootstrap (Only required if building from git repository). 
> $ ./bootstrap
> Logs:
> 3rdparty/stout/Makefile.am:71: warning: source file 
> 'tests/subcommand_tests.cpp' is in a subdirectory,
> 3rdparty/stout/Makefile.am:71: but option 'subdir-objects' is disabled
> 3rdparty/stout/Makefile.am:71: warning: source file 'tests/svn_tests.cpp' is 
> in a subdirectory,
> 3rdparty/stout/Makefile.am:71: but option 'subdir-objects' is disabled
> 3rdparty/stout/Makefile.am:71: warning: source file 'tests/try_tests.cpp' is 
> in a subdirectory,
> 3rdparty/stout/Makefile.am:71: but option 'subdir-objects' is disabled
> 3rdparty/stout/Makefile.am:71: warning: source file 'tests/uuid_tests.cpp' is 
> in a subdirectory,
> 3rdparty/stout/Makefile.am:71: but option 'subdir-objects' is disabled
> 3rdparty/stout/Makefile.am:71: warning: source file 'tests/version_tests.cpp' 
> is in a subdirectory,
> 3rdparty/stout/Makefile.am:71: but option 'subdir-objects' is disabled
> 3rdparty/stout/Makefile.am:122: warning: source file 'tests/proc_tests.cpp' 
> is in a subdirectory,
> 3rdparty/stout/Makefile.am:122: but option 'subdir-objects' is disabled



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

[jira] [Updated] (MESOS-5520) Before starting a build, bootstrapping shows some warning

[Ankur Verma (JIRA)]

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

Ankur Verma updated MESOS-5520:
---
Attachment: bootstrap_cmd_logs.txt

while executing the command bootstrap following logs comes

> Before starting a build, bootstrapping shows some warning
> -
>
> Key: MESOS-5520
> URL: https://issues.apache.org/jira/browse/MESOS-5520
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Affects Versions: 0.28.1
> Environment: ubuntu 14.04.4
>Reporter: Ankur Verma
>Priority: Minor
> Attachments: bootstrap_cmd_logs.txt
>
>
> For the first time before building, some warning comes when using command 
> bootstrap
> # Bootstrap (Only required if building from git repository). 
> $ ./bootstrap
> Logs:
> 3rdparty/stout/Makefile.am:71: warning: source file 
> 'tests/subcommand_tests.cpp' is in a subdirectory,
> 3rdparty/stout/Makefile.am:71: but option 'subdir-objects' is disabled
> 3rdparty/stout/Makefile.am:71: warning: source file 'tests/svn_tests.cpp' is 
> in a subdirectory,
> 3rdparty/stout/Makefile.am:71: but option 'subdir-objects' is disabled
> 3rdparty/stout/Makefile.am:71: warning: source file 'tests/try_tests.cpp' is 
> in a subdirectory,
> 3rdparty/stout/Makefile.am:71: but option 'subdir-objects' is disabled
> 3rdparty/stout/Makefile.am:71: warning: source file 'tests/uuid_tests.cpp' is 
> in a subdirectory,
> 3rdparty/stout/Makefile.am:71: but option 'subdir-objects' is disabled
> 3rdparty/stout/Makefile.am:71: warning: source file 'tests/version_tests.cpp' 
> is in a subdirectory,
> 3rdparty/stout/Makefile.am:71: but option 'subdir-objects' is disabled
> 3rdparty/stout/Makefile.am:122: warning: source file 'tests/proc_tests.cpp' 
> is in a subdirectory,
> 3rdparty/stout/Makefile.am:122: but option 'subdir-objects' is disabled



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

[jira] [Commented] (MESOS-5520) Before starting a build, bootstrapping shows some warning

[Ankur Verma (JIRA)]

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

Ankur Verma commented on MESOS-5520:


automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same 
subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
3rdparty/Makefile.am: installing './depcomp'
3rdparty/Makefile.am:150: warning: variable 'GLOG_LDFLAGS' is defined but no 
program or
3rdparty/Makefile.am:150: library has 'GLOG' as canonical name (possible typo)
3rdparty/libprocess/Makefile.am:95: warning: source file 
'src/authenticator_manager.cpp' is in a subdirectory,
3rdparty/libprocess/Makefile.am:95: but option 'subdir-objects' is disabled
3rdparty/libprocess/Makefile.am:95: warning: source file 
'src/authenticator.cpp' is in a subdirectory,
3rdparty/libprocess/Makefile.am:95: but option 'subdir-objects' is disabled
3rdparty/libprocess/Makefile.am:95: warning: source file 'src/clock.cpp' is in 
a subdirectory,
3rdparty/libprocess/Makefile.am:95: but option 'subdir-objects' is disabled
3rdparty/libprocess/Makefile.am:95: warning: source file 'src/firewall.cpp' is 
in a subdirectory,

> Before starting a build, bootstrapping shows some warning
> -
>
> Key: MESOS-5520
> URL: https://issues.apache.org/jira/browse/MESOS-5520
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Affects Versions: 0.28.1
> Environment: ubuntu 14.04.4
>Reporter: Ankur Verma
>Priority: Minor
>
> For the first time before building, some warning comes when using command 
> bootstrap
> # Bootstrap (Only required if building from git repository). 
> $ ./bootstrap
> Logs:
> 3rdparty/stout/Makefile.am:71: warning: source file 
> 'tests/subcommand_tests.cpp' is in a subdirectory,
> 3rdparty/stout/Makefile.am:71: but option 'subdir-objects' is disabled
> 3rdparty/stout/Makefile.am:71: warning: source file 'tests/svn_tests.cpp' is 
> in a subdirectory,
> 3rdparty/stout/Makefile.am:71: but option 'subdir-objects' is disabled
> 3rdparty/stout/Makefile.am:71: warning: source file 'tests/try_tests.cpp' is 
> in a subdirectory,
> 3rdparty/stout/Makefile.am:71: but option 'subdir-objects' is disabled
> 3rdparty/stout/Makefile.am:71: warning: source file 'tests/uuid_tests.cpp' is 
> in a subdirectory,
> 3rdparty/stout/Makefile.am:71: but option 'subdir-objects' is disabled
> 3rdparty/stout/Makefile.am:71: warning: source file 'tests/version_tests.cpp' 
> is in a subdirectory,
> 3rdparty/stout/Makefile.am:71: but option 'subdir-objects' is disabled
> 3rdparty/stout/Makefile.am:122: warning: source file 'tests/proc_tests.cpp' 
> is in a subdirectory,
> 3rdparty/stout/Makefile.am:122: but option 'subdir-objects' is disabled



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

[jira] [Created] (MESOS-5520) Before starting a build, bootstrapping shows some warning

[Ankur Verma (JIRA)]

Ankur Verma created MESOS-5520:
--

 Summary: Before starting a build, bootstrapping shows some warning
 Key: MESOS-5520
 URL: https://issues.apache.org/jira/browse/MESOS-5520
 Project: Mesos
  Issue Type: Bug
  Components: build
Affects Versions: 0.28.1
 Environment: ubuntu 14.04.4
Reporter: Ankur Verma
Priority: Minor


For the first time before building, some warning comes when using command 
bootstrap

# Bootstrap (Only required if building from git repository). 
$ ./bootstrap

Logs:

3rdparty/stout/Makefile.am:71: warning: source file 
'tests/subcommand_tests.cpp' is in a subdirectory,
3rdparty/stout/Makefile.am:71: but option 'subdir-objects' is disabled
3rdparty/stout/Makefile.am:71: warning: source file 'tests/svn_tests.cpp' is in 
a subdirectory,
3rdparty/stout/Makefile.am:71: but option 'subdir-objects' is disabled
3rdparty/stout/Makefile.am:71: warning: source file 'tests/try_tests.cpp' is in 
a subdirectory,
3rdparty/stout/Makefile.am:71: but option 'subdir-objects' is disabled
3rdparty/stout/Makefile.am:71: warning: source file 'tests/uuid_tests.cpp' is 
in a subdirectory,
3rdparty/stout/Makefile.am:71: but option 'subdir-objects' is disabled
3rdparty/stout/Makefile.am:71: warning: source file 'tests/version_tests.cpp' 
is in a subdirectory,
3rdparty/stout/Makefile.am:71: but option 'subdir-objects' is disabled
3rdparty/stout/Makefile.am:122: warning: source file 'tests/proc_tests.cpp' is 
in a subdirectory,
3rdparty/stout/Makefile.am:122: but option 'subdir-objects' is disabled




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

[jira] [Assigned] (MESOS-5512) Implement GET_LOGGING_LEVEL Call in v1 agent API.

[haosdent (JIRA)]

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

haosdent reassigned MESOS-5512:
---

Assignee: haosdent

> Implement GET_LOGGING_LEVEL Call in v1 agent API.
> -
>
> Key: MESOS-5512
> URL: https://issues.apache.org/jira/browse/MESOS-5512
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: haosdent
>




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

[jira] [Updated] (MESOS-5501) Implement CREATE_VOLUMES Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta updated MESOS-5501:
-
Assignee: (was: Abhishek Dasgupta)

> Implement CREATE_VOLUMES Call in v1 master API.
> ---
>
> Key: MESOS-5501
> URL: https://issues.apache.org/jira/browse/MESOS-5501
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>




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

[jira] [Assigned] (MESOS-5510) Implement REMOVE_QUOTA Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5510:


Assignee: Abhishek Dasgupta

> Implement REMOVE_QUOTA Call in v1 master API.
> -
>
> Key: MESOS-5510
> URL: https://issues.apache.org/jira/browse/MESOS-5510
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Assigned] (MESOS-5508) Implement GET_QUOTA Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5508:


Assignee: Abhishek Dasgupta

> Implement GET_QUOTA Call in v1 master API.
> --
>
> Key: MESOS-5508
> URL: https://issues.apache.org/jira/browse/MESOS-5508
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Assigned] (MESOS-5509) Implement SET_QUOTA Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5509:


Assignee: Abhishek Dasgupta

> Implement SET_QUOTA Call in v1 master API.
> --
>
> Key: MESOS-5509
> URL: https://issues.apache.org/jira/browse/MESOS-5509
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Updated] (MESOS-5502) Implement DESTROY_VOLUMES Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta updated MESOS-5502:
-
Assignee: (was: Abhishek Dasgupta)

> Implement DESTROY_VOLUMES Call in v1 master API.
> 
>
> Key: MESOS-5502
> URL: https://issues.apache.org/jira/browse/MESOS-5502
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>




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

[jira] [Assigned] (MESOS-5502) Implement DESTROY_VOLUMES Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5502:


Assignee: Abhishek Dasgupta

> Implement DESTROY_VOLUMES Call in v1 master API.
> 
>
> Key: MESOS-5502
> URL: https://issues.apache.org/jira/browse/MESOS-5502
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Assigned] (MESOS-5501) Implement CREATE_VOLUMES Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5501:


Assignee: Abhishek Dasgupta

> Implement CREATE_VOLUMES Call in v1 master API.
> ---
>
> Key: MESOS-5501
> URL: https://issues.apache.org/jira/browse/MESOS-5501
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Assigned] (MESOS-5500) Implement UNRESERVE_RESOURCES Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5500:


Assignee: Abhishek Dasgupta

> Implement UNRESERVE_RESOURCES Call in v1 master API.
> 
>
> Key: MESOS-5500
> URL: https://issues.apache.org/jira/browse/MESOS-5500
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Assigned] (MESOS-5499) Implement RESERVE_RESOURCES Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5499:


Assignee: Abhishek Dasgupta

> Implement RESERVE_RESOURCES Call in v1 master API.
> --
>
> Key: MESOS-5499
> URL: https://issues.apache.org/jira/browse/MESOS-5499
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Assigned] (MESOS-5497) Implement GET_LEADING_MASTER Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5497:


Assignee: Abhishek Dasgupta

> Implement GET_LEADING_MASTER Call in v1 master API.
> ---
>
> Key: MESOS-5497
> URL: https://issues.apache.org/jira/browse/MESOS-5497
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Assigned] (MESOS-5494) Implement GET_ROLES Call in v1 master API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5494:


Assignee: Abhishek Dasgupta

> Implement GET_ROLES Call in v1 master API.
> --
>
> Key: MESOS-5494
> URL: https://issues.apache.org/jira/browse/MESOS-5494
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Assigned] (MESOS-5514) Implement LIST_FILES Call in v1 agent API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5514:


Assignee: Abhishek Dasgupta

> Implement LIST_FILES Call in v1 agent API.
> --
>
> Key: MESOS-5514
> URL: https://issues.apache.org/jira/browse/MESOS-5514
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Assigned] (MESOS-5517) Implement GET_RESOURCE_STATISTICS Call in v1 agent API.

[Abhishek Dasgupta (JIRA)]

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

Abhishek Dasgupta reassigned MESOS-5517:


Assignee: Abhishek Dasgupta

> Implement GET_RESOURCE_STATISTICS Call in v1 agent API.
> ---
>
> Key: MESOS-5517
> URL: https://issues.apache.org/jira/browse/MESOS-5517
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Abhishek Dasgupta
>




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

[jira] [Commented] (MESOS-3067) Implement a streaming response decoder for events stream

[Vinod Kone (JIRA)]

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

Vinod Kone commented on MESOS-3067:
---

We chose RecordIO format because it can be applied consistently to both JSON 
and serialized protobufs. As for the content type, agree that application/json 
is incorrect but that is what Twitter streaming API and other APIs I have 
looked around that does RecordIO streaming call it :( Maybe we should call it 
application/x-json-recordio?

> Implement a streaming response decoder for events stream
> 
>
> Key: MESOS-3067
> URL: https://issues.apache.org/jira/browse/MESOS-3067
> Project: Mesos
>  Issue Type: Task
>Reporter: Anand Mazumdar
>Assignee: Benjamin Mahler
> Fix For: 0.24.0
>
>
> We need a streaming response decoder to de-serialize chunks sent from the 
> master on the events stream.
> From the HTTP API design doc:
> Master encodes each Event in RecordIO format, i.e. a string representation of 
> length of the event in bytes followed by JSON or binary Protobuf  (possibly 
> compressed) encoded event.
> As of now for getting the basic features right , this is being done in the 
> test-cases:
> {code}
>   auto reader = response.get().reader;
>   ASSERT_SOME(reader);
>   Future eventFuture = reader.get().read();
>   AWAIT_READY(eventFuture);
>   Event event;
>   event.ParseFromString(eventFuture.get());
> {code}
> Two things need to happen:
> - We need master to emit events in RecordIO format i.e. event size followed 
> by the serialized event instead of just the serialized events as is the case 
> now.
> - The decoder class should then abstract away the logic of reading the 
> response and de-serializing events from the stream.
> Ideally, the decoder should work with both "json" and "protobuf" responses.



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

[jira] [Comment Edited] (MESOS-3067) Implement a streaming response decoder for events stream

[Vinod Kone (JIRA)]

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

Vinod Kone edited comment on MESOS-3067 at 5/30/16 6:30 AM:


We chose RecordIO format because it can be applied consistently to both JSON 
and serialized protobufs. As for the content type, agree that application/json 
is incorrect but that is what Twitter streaming API and other APIs I have 
looked around that does RecordIO streaming call it :( Maybe we should call it 
application/x-json-recordio and application/x-protobuf-recordio respectively?


was (Author: vinodkone):
We chose RecordIO format because it can be applied consistently to both JSON 
and serialized protobufs. As for the content type, agree that application/json 
is incorrect but that is what Twitter streaming API and other APIs I have 
looked around that does RecordIO streaming call it :( Maybe we should call it 
application/x-json-recordio?

> Implement a streaming response decoder for events stream
> 
>
> Key: MESOS-3067
> URL: https://issues.apache.org/jira/browse/MESOS-3067
> Project: Mesos
>  Issue Type: Task
>Reporter: Anand Mazumdar
>Assignee: Benjamin Mahler
> Fix For: 0.24.0
>
>
> We need a streaming response decoder to de-serialize chunks sent from the 
> master on the events stream.
> From the HTTP API design doc:
> Master encodes each Event in RecordIO format, i.e. a string representation of 
> length of the event in bytes followed by JSON or binary Protobuf  (possibly 
> compressed) encoded event.
> As of now for getting the basic features right , this is being done in the 
> test-cases:
> {code}
>   auto reader = response.get().reader;
>   ASSERT_SOME(reader);
>   Future eventFuture = reader.get().read();
>   AWAIT_READY(eventFuture);
>   Event event;
>   event.ParseFromString(eventFuture.get());
> {code}
> Two things need to happen:
> - We need master to emit events in RecordIO format i.e. event size followed 
> by the serialized event instead of just the serialized events as is the case 
> now.
> - The decoder class should then abstract away the logic of reading the 
> response and de-serializing events from the stream.
> Ideally, the decoder should work with both "json" and "protobuf" responses.



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

[jira] [Assigned] (MESOS-5493) Implement GET_TASKS Call in v1 master API.

[Jay Guo (JIRA)]

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

Jay Guo reassigned MESOS-5493:
--

Assignee: Jay Guo

> Implement GET_TASKS Call in v1 master API.
> --
>
> Key: MESOS-5493
> URL: https://issues.apache.org/jira/browse/MESOS-5493
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Jay Guo
>




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