[jira] [Commented] (MESOS-4735) CommandInfo.URI should allow specifying target filename

[Yan Xu (JIRA)]

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

Yan Xu commented on MESOS-4735:
---

Note: The protobuf field 'filename' is renamed 'output_file' in MESOS-5119.

> CommandInfo.URI should allow specifying target filename
> ---
>
> Key: MESOS-4735
> URL: https://issues.apache.org/jira/browse/MESOS-4735
> Project: Mesos
>  Issue Type: Improvement
>  Components: fetcher
>Reporter: Erik Weathers
>Assignee: Michael Browning
>Priority: Minor
> Fix For: 0.29.0
>
>
> The {{CommandInfo.URI}} message should allow explicitly choosing the 
> downloaded file's name, to better mimic functionality present in tools like 
> {{wget}} and {{curl}}.
> This relates to issues when the {{CommandInfo.URI}} is pointing to a URL that 
> has query parameters at the end of the path, resulting in the downloaded 
> filename having those elements.  This also prevents extracting of such files, 
> since the extraction logic is simply looking at the file's suffix. See 
> MESOS-3367, MESOS-1686, and MESOS-1509 for more info.  If this issue was 
> fixed, then I could workaround the other issues not being fixed by modifying 
> my framework's scheduler to set the target filename.



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

[jira] [Commented] (MESOS-5119) Support directory structure in CommandInfo.URI.filename in fetcher

[Yan Xu (JIRA)]

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

Yan Xu commented on MESOS-5119:
---

Note: The protobuf field 'filename' is renamed 'output_file' due to this usage 
change.

> Support directory structure in CommandInfo.URI.filename in fetcher
> --
>
> Key: MESOS-5119
> URL: https://issues.apache.org/jira/browse/MESOS-5119
> Project: Mesos
>  Issue Type: Improvement
>  Components: fetcher
>Reporter: Yan Xu
>Assignee: Michael Browning
>
> In MESOS-4735, {{CommandInfo.URI.filename}} is added but there is no 
> validation to make sure it's a simple basename, so people can actually 
> specify the filename to be something like {{path/to/file}} but the validation 
> [won't catch it|https://reviews.apache.org/r/45046/#comment190155]. The fetch 
> will fail later in {{download()}} because it cannot open a destination file 
> without its parent directory.
> Instead of fixing this by disallowing such output filename, we could actually 
> support this behavior. There are use cases where multiple fetch targets have 
> the same basename but they are organized by a directory hierarchy.
> {noformat:title=}
> root/app.dat
> root/parent/app.dat
> root/parent/child/app.dat
> {noformat}
> It looks to me that supporting this is straightforward and we just need to 1) 
> make sure the output path is within the sandbox and 2) recursively mkdirs for 
> the parent dirs.



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

[jira] [Commented] (MESOS-5119) Support directory structure in CommandInfo.URI.filename in fetcher

[Yan Xu (JIRA)]

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

Yan Xu commented on MESOS-5119:
---

{noformat:title=}
commit 3d2d3edb96c9c428f988653cdd4428a05690e747
Author: Michael Browning 
Date:   Fri Apr 22 17:48:24 2016 -0700

Add subdirectory support to URI.output_file field.

URI.output_file allows the user to specify the path of the file that'll
be saved in the sandbox when the URI is fetched, but previously it would
fail at fetch time if "filename" had a directory component. This change
allows users to specify a relative path for custom ouput targets within
the sandbox.

The protobuf field 'filename' is renamed 'output_file' due to this
usage change.

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

> Support directory structure in CommandInfo.URI.filename in fetcher
> --
>
> Key: MESOS-5119
> URL: https://issues.apache.org/jira/browse/MESOS-5119
> Project: Mesos
>  Issue Type: Improvement
>  Components: fetcher
>Reporter: Yan Xu
>Assignee: Michael Browning
>
> In MESOS-4735, {{CommandInfo.URI.filename}} is added but there is no 
> validation to make sure it's a simple basename, so people can actually 
> specify the filename to be something like {{path/to/file}} but the validation 
> [won't catch it|https://reviews.apache.org/r/45046/#comment190155]. The fetch 
> will fail later in {{download()}} because it cannot open a destination file 
> without its parent directory.
> Instead of fixing this by disallowing such output filename, we could actually 
> support this behavior. There are use cases where multiple fetch targets have 
> the same basename but they are organized by a directory hierarchy.
> {noformat:title=}
> root/app.dat
> root/parent/app.dat
> root/parent/child/app.dat
> {noformat}
> It looks to me that supporting this is straightforward and we just need to 1) 
> make sure the output path is within the sandbox and 2) recursively mkdirs for 
> the parent dirs.



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

[jira] [Created] (MESOS-5262) slave::statusUpdate() should always ACK the status update sent by executor

[Qian Zhang (JIRA)]

Qian Zhang created MESOS-5262:
-

 Summary: slave::statusUpdate() should always ACK the status update 
sent by executor
 Key: MESOS-5262
 URL: https://issues.apache.org/jira/browse/MESOS-5262
 Project: Mesos
  Issue Type: Improvement
  Components: slave
Reporter: Qian Zhang


In {{slave::statusUpdate()}}, there are several scenarios where agent ignores a 
status update sent by the executor and will not send an ACK to the executor, 
e.g.:

When agent receives a {{ShutdownFrameworkMessage}} from master, 
{{slave::shutdownFramework()}} will be called. In this method, we will set the 
state of framework to {{TERMINATING}} and send a {{ShutdownExecutorMessage}} to 
executor. When executor receives that message, usually it will kill the tasks 
and send {{TASK_KILLED}} status update to agent. Agent will receive that 
message and handle it in {{slave::statusUpdate()}}, but according to the 
currently logic of {{slave::statusUpdate()}}, it will ignore the status update 
if the state of framework is {{TERMINATING}}, so agent will not send an ACK to 
the executor.

Since executor may rely on the ACK (e.g., HTTP command executor relies on the 
ACK of a terminal status update to terminate itself), we should enhance it such 
that executor can always get an ACK for the status update sent by it.



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

[jira] [Comment Edited] (MESOS-5251) Enable "--explicitcreate" when call "dvdcli mount"

[Guangya Liu (JIRA)]

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

Guangya Liu edited comment on MESOS-5251 at 4/23/16 2:16 AM:
-

https://reviews.apache.org/r/45671/
https://reviews.apache.org/r/45275/


was (Author: gyliu):
https://reviews.apache.org/r/45275/

> Enable "--explicitcreate" when call "dvdcli mount"
> --
>
> Key: MESOS-5251
> URL: https://issues.apache.org/jira/browse/MESOS-5251
> Project: Mesos
>  Issue Type: Bug
>Reporter: Guangya Liu
>Assignee: Guangya Liu
>
> The dvdcli 0.1.0 will create volume by default if the volume does not exist 
> when mounting, this is not a good behavior to create volumes blindly. Please 
> refer to https://github.com/docker/docker/issues/21829 for some discussion 
> with docker community.
> The dvdcli has fixed this issue by introducing a new flag "--explicitcreate"  
> to enable end user can customize the behavior of creating the volume by 
> default or not. Please refer to https://github.com/emccode/dvdcli/issues/18 
> for some detail.



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

[jira] [Commented] (MESOS-1575) master sets failover timeout to 0 when framework requests a high value

[JIRA]

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

José Guilherme Vanz commented on MESOS-1575:


[~vinodkone] ping

> master sets failover timeout to 0 when framework requests a high value
> --
>
> Key: MESOS-1575
> URL: https://issues.apache.org/jira/browse/MESOS-1575
> Project: Mesos
>  Issue Type: Bug
>Reporter: Kevin Sweeney
>Assignee: José Guilherme Vanz
>  Labels: newbie, twitter
>
> In response to a registered RPC we observed the following behavior:
> {noformat}
> W0709 19:07:32.982997 11400 master.cpp:612] Using the default value for 
> 'failover_timeout' becausethe input value is invalid: Argument out of the 
> range that a Duration can represent due to int64_t's size limit
> I0709 19:07:32.983008 11404 hierarchical_allocator_process.hpp:408] 
> Deactivated framework 20140709-184342-119646400-5050-11380-0003
> I0709 19:07:32.983013 11400 master.cpp:617] Giving framework 
> 20140709-184342-119646400-5050-11380-0003 0ns to failover
> I0709 19:07:32.983271 11404 master.cpp:2201] Framework failover timeout, 
> removing framework 20140709-184342-119646400-5050-11380-0003
> I0709 19:07:32.983294 11404 master.cpp:2688] Removing framework 
> 20140709-184342-119646400-5050-11380-0003
> I0709 19:07:32.983678 11404 hierarchical_allocator_process.hpp:363] Removed 
> framework 20140709-184342-119646400-5050-11380-0003
> {noformat}
> This was using the following frameworkInfo.
> {code}
> FrameworkInfo frameworkInfo = FrameworkInfo.newBuilder()
> .setUser("test")
> .setName("jvm")
> .setFailoverTimeout(Long.MAX_VALUE)
> .build();
> {code}
> Instead of silently defaulting large values to 0 the master should refuse to 
> process the request.



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

[jira] [Comment Edited] (MESOS-5254) Add URI parsing function/library

[Joseph Wu (JIRA)]

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

Joseph Wu edited comment on MESOS-5254 at 4/23/16 12:49 AM:


|| Review || Summary ||
| https://reviews.apache.org/r/46580/ | Bundled dependency | 
| https://reviews.apache.org/r/46588/ | {{URI::parse}} |

Supplementary patch: https://reviews.apache.org/r/46551/
^ This is meant to demonstrate {{uriparser}}'s API.  It is not meant to be 
committed. 


was (Author: kaysoky):
Review: https://reviews.apache.org/r/46580/

Supplementary patch: https://reviews.apache.org/r/46551/
^ This is meant to demonstrate {{uriparser}}'s API.  It is not meant to be 
committed. 

> Add URI parsing function/library
> 
>
> Key: MESOS-5254
> URL: https://issues.apache.org/jira/browse/MESOS-5254
> Project: Mesos
>  Issue Type: Task
>  Components: fetcher, libprocess
>Reporter: Joseph Wu
>Assignee: Joseph Wu
>  Labels: mesosphere
>
> The {{uri::Fetcher}} theoretically supports all URIs, per 
> [RFC3986|http://tools.ietf.org/html/rfc3986].  To do this, we need a 
> spec-compliant parser from string to URI.
> [uriparser|http://uriparser.sourceforge.net/] appears to fit the bill.



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

[jira] [Created] (MESOS-5261) Combine the internal::slave::Fetcher class and mesos-fetcher binary

[Joseph Wu (JIRA)]

Joseph Wu created MESOS-5261:


 Summary: Combine the internal::slave::Fetcher class and 
mesos-fetcher binary
 Key: MESOS-5261
 URL: https://issues.apache.org/jira/browse/MESOS-5261
 Project: Mesos
  Issue Type: Task
  Components: fetcher
Reporter: Joseph Wu
Assignee: Joseph Wu


After [MESOS-5259], the {{mesos-fetcher}} will no longer need to be a separate 
binary and can be safely folded back into the agent process.  (It was a 
separate binary because libcurl has synchronous/blocking calls.)  

This will likely mean:
* A change to the {{fetch}} continuation chain:
  
https://github.com/apache/mesos/blob/653eca74f1080f5f55cd5092423506163e65d402/src/slave/containerizer/fetcher.cpp#L315
* This protobuf can be deprecated (or just removed):
  
https://github.com/apache/mesos/blob/653eca74f1080f5f55cd5092423506163e65d402/include/mesos/fetcher/fetcher.proto



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

[jira] [Created] (MESOS-5260) Extend the uri::Fetcher::Plugin interface to include a "fetchSize"

[Joseph Wu (JIRA)]

Joseph Wu created MESOS-5260:


 Summary: Extend the uri::Fetcher::Plugin interface to include a 
"fetchSize"
 Key: MESOS-5260
 URL: https://issues.apache.org/jira/browse/MESOS-5260
 Project: Mesos
  Issue Type: Task
  Components: fetcher
Reporter: Joseph Wu
Assignee: Joseph Wu


In order to replace the {{mesos-fetcher}} binary with the {{uri::Fetcher}}, 
each plugin must be able to determine/estimate the size of a download.  This is 
used by the Fetcher cache when it creates cache entries and such.

The logic for each of the four {{Fetcher::Plugin}}s can be taken and refactored 
from the existing fetcher.
https://github.com/apache/mesos/blob/653eca74f1080f5f55cd5092423506163e65d402/src/slave/containerizer/fetcher.cpp#L267



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

[jira] [Created] (MESOS-5259) Refactor the mesos-fetcher binary to use the uri::Fetcher as a backend

[Joseph Wu (JIRA)]

Joseph Wu created MESOS-5259:


 Summary: Refactor the mesos-fetcher binary to use the uri::Fetcher 
as a backend
 Key: MESOS-5259
 URL: https://issues.apache.org/jira/browse/MESOS-5259
 Project: Mesos
  Issue Type: Task
  Components: fetcher
Reporter: Joseph Wu
Assignee: Joseph Wu


This is an intermediate step for combining the {{mesos-fetcher}} binary and 
{{uri::Fetcher}}.  

The {{download}} method should be replaced with {{uri::Fetcher::fetch}}.
https://github.com/apache/mesos/blob/653eca74f1080f5f55cd5092423506163e65d402/src/launcher/fetcher.cpp#L179

Combining the two will:
* Attach the {{uri::Fetcher}} to the existing Fetcher caching logic.
* Remove some code duplication for downloading URIs.



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

[jira] [Commented] (MESOS-5227) Implement HTTP Docker Executor that uses the Executor Library

[Qian Zhang (JIRA)]

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

Qian Zhang commented on MESOS-5227:
---

[~alexr], yeah, I'd like to :-)

> Implement HTTP Docker Executor that uses the Executor Library
> -
>
> Key: MESOS-5227
> URL: https://issues.apache.org/jira/browse/MESOS-5227
> Project: Mesos
>  Issue Type: Bug
>Reporter: Vinod Kone
>Assignee: Yong Tang
>
> Similar to what we did with the HTTP command executor in MESOS-3558 we should 
> have a HTTP docker executor that can speak the v1 Executor API.



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

[jira] [Created] (MESOS-5258) Turn the Nvidia GPU isolator into a module

[Kevin Klues (JIRA)]

Kevin Klues created MESOS-5258:
--

 Summary: Turn the Nvidia GPU isolator into a module
 Key: MESOS-5258
 URL: https://issues.apache.org/jira/browse/MESOS-5258
 Project: Mesos
  Issue Type: Task
Reporter: Kevin Klues


The Nvidia GPU isolator has an external dependence on `libnvidia-ml.so`. As it 
currently stands, this forces *all* binaries that link with `libmesos.so` to 
also link with `libnvidia-ml.so` (including master, agents on machines without 
GPUs, scheduler, exectors, etc.).

By turning the Nvidia GPU isolator into a module, it will be loaded at runtime 
only when an agent has explicitly including the the Nvidia GPU isolator in its 
`--isolation` flag.



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

[jira] [Updated] (MESOS-5253) Isolator cleanup should not be invoked if they are not prepared yet.

[Jie Yu (JIRA)]

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

Jie Yu updated MESOS-5253:
--
Fix Version/s: 0.28.2

> Isolator cleanup should not be invoked if they are not prepared yet.
> 
>
> Key: MESOS-5253
> URL: https://issues.apache.org/jira/browse/MESOS-5253
> Project: Mesos
>  Issue Type: Bug
>  Components: containerization
>Affects Versions: 0.28.0, 0.28.1
>Reporter: Gilbert Song
>Assignee: Gilbert Song
>  Labels: containerizer
> Fix For: 0.29.0, 0.28.2
>
>
> If the mesos containerizer destroys a container in PROVISIONING state, 
> isolator cleanup is still called, which is incorrect because there is no 
> isolator prepared yet. 
> In this case, there no need to clean up any isolator, call provisioner 
> destroy directly.



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

[jira] [Commented] (MESOS-4760) Expose metrics and gauges for fetcher cache usage and hit rate

[Michael Browning (JIRA)]

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

Michael Browning commented on MESOS-4760:
-

Having dug into turning the metrics-gathering logic I wrote into Metrics, I 
think there's not a good way to do this without having the Slave process retain 
a reference to the Fetcher, as some of the TODOs in fetcher.hpp indicate is in 
the cards. [~bernd-mesos], do you think that's coming soon? I could take it on, 
if not.

> Expose metrics and gauges for fetcher cache usage and hit rate
> --
>
> Key: MESOS-4760
> URL: https://issues.apache.org/jira/browse/MESOS-4760
> Project: Mesos
>  Issue Type: Improvement
>  Components: fetcher, statistics
>Reporter: Michael Browning
>Assignee: Michael Browning
>Priority: Minor
>  Labels: features, fetcher, statistics, uber
>
> To evaluate the fetcher cache and calibrate the value of the 
> fetcher_cache_size flag, it would be useful to have metrics and gauges on 
> agents that expose operational statistics like cache hit rate, occupied cache 
> size, and time spent downloading resources that were not present.



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

[jira] [Updated] (MESOS-5257) Add autodiscovery for GPU resources

[Kevin Klues (JIRA)]

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

Kevin Klues updated MESOS-5257:
---
Labels: isolator  (was: )

> Add autodiscovery for GPU resources
> ---
>
> Key: MESOS-5257
> URL: https://issues.apache.org/jira/browse/MESOS-5257
> Project: Mesos
>  Issue Type: Task
>Reporter: Kevin Klues
>  Labels: isolator
>
> Right now, the only way to enumerate the available GPUs on an agent is to use 
> the `--nvidia_gpu_devices` flag and explicitly list them out.  Instead, we 
> should leverage NVML to autodiscover the GPUs that are available and only use 
> this flag as a way to explicitly list out the GPUs you want to make available 
> in order to restrict access to some of them.



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

[jira] [Commented] (MESOS-5257) Add autodiscovery for GPU resources

[Kevin Klues (JIRA)]

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

Kevin Klues commented on MESOS-5257:


GPU autodiscovery should be implemented inside the isolator-specific 
`resources()` callback that is part of the linked ticket.

> Add autodiscovery for GPU resources
> ---
>
> Key: MESOS-5257
> URL: https://issues.apache.org/jira/browse/MESOS-5257
> Project: Mesos
>  Issue Type: Task
>Reporter: Kevin Klues
>
> Right now, the only way to enumerate the available GPUs on an agent is to use 
> the `--nvidia_gpu_devices` flag and explicitly list them out.  Instead, we 
> should leverage NVML to autodiscover the GPUs that are available and only use 
> this flag as a way to explicitly list out the GPUs you want to make available 
> in order to restrict access to some of them.



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

[jira] [Created] (MESOS-5257) Add autodiscovery for GPU resources

[Kevin Klues (JIRA)]

Kevin Klues created MESOS-5257:
--

 Summary: Add autodiscovery for GPU resources
 Key: MESOS-5257
 URL: https://issues.apache.org/jira/browse/MESOS-5257
 Project: Mesos
  Issue Type: Task
Reporter: Kevin Klues


Right now, the only way to enumerate the available GPUs on an agent is to use 
the `--nvidia_gpu_devices` flag and explicitly list them out.  Instead, we 
should leverage NVML to autodiscover the GPUs that are available and only use 
this flag as a way to explicitly list out the GPUs you want to make available 
in order to restrict access to some of them.



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

[jira] [Created] (MESOS-5256) Add support for per-containerizer resource enumeration

[Kevin Klues (JIRA)]

Kevin Klues created MESOS-5256:
--

 Summary: Add support for per-containerizer resource enumeration
 Key: MESOS-5256
 URL: https://issues.apache.org/jira/browse/MESOS-5256
 Project: Mesos
  Issue Type: Task
  Components: isolation
Reporter: Kevin Klues
Assignee: Kevin Klues


Currently the top level containerizer includes a static function for 
enumerating the resources available on a given agent. Ideally, this 
functionality should be the responsibility of individual containerizers (and 
specifically the responsibility of each isolator used to control access to 
those resources).

Adding support for this will involve making the `Containerizer::resources()` 
function virtual instead of static and then implementing it on a 
per-containerizer basis.  We should consider providing a default to make this 
easier in cases where there is only really one good way of enumerating a given 
set of resources.



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

[jira] [Updated] (MESOS-5255) Add GPUs to container resource consumption metrics.

[Benjamin Mahler (JIRA)]

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

Benjamin Mahler updated MESOS-5255:
---
Summary: Add GPUs to container resource consumption metrics.  (was: Add 
support for GPU usage in metrics endpoint)

> Add GPUs to container resource consumption metrics.
> ---
>
> Key: MESOS-5255
> URL: https://issues.apache.org/jira/browse/MESOS-5255
> Project: Mesos
>  Issue Type: Task
>Reporter: Kevin Klues
>  Labels: gpu
>
> Currently the usage callback in the Nvidia GPU isolator is unimplemented:
> {noformat}
> src/slave/containerizer/mesos/isolators/cgroups/devices/gpus/nvidia.cpp
> {noformat}
> It should use functionality from NVML to gather the current GPU usage and add 
> it to a ResourceStatistics object. It is still an open question as to exactly 
> what information we want to expose here (power, memory consumption, current 
> load, etc.). Whatever we decide on should be standard across different GPU 
> types, different GPU vendors, etc.



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

[jira] [Updated] (MESOS-5255) Add support for GPU usage in metrics endpoint

[Kevin Klues (JIRA)]

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

Kevin Klues updated MESOS-5255:
---
Assignee: (was: Kevin Klues)

> Add support for GPU usage in metrics endpoint
> -
>
> Key: MESOS-5255
> URL: https://issues.apache.org/jira/browse/MESOS-5255
> Project: Mesos
>  Issue Type: Task
>Reporter: Kevin Klues
>  Labels: gpu
>
> Currently the usage callback in the Nvidia GPU isolator is unimplemented:
> {noformat}
> src/slave/containerizer/mesos/isolators/cgroups/devices/gpus/nvidia.cpp
> {noformat}
> It should use functionality from NVML to gather the current GPU usage and add 
> it to a ResourceStatistics object. It is still an open question as to exactly 
> what information we want to expose here (power, memory consumption, current 
> load, etc.). Whatever we decide on should be standard across different GPU 
> types, different GPU vendors, etc.



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

[jira] [Commented] (MESOS-5255) Add support for GPU usage in metrics endpoint

[Kevin Klues (JIRA)]

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

Kevin Klues commented on MESOS-5255:


This will involve changes to the ResourceStatistics protobuf as well:
{noformat}
include/mesos/mesos.proto
include/mesos/v1/mesos.proto
{noformat}

It will also involve changes to the webui to report this information (in file):
{noformat}
src/webui/master/static/slave_executor.html
{noformat}

Look for the line below and mimic what is done for CPUs:
{noformat}
GPUs

  N/A

{noformat}

Also in:
{noformat}
src/webui/master/static/slave_framework.html
{noformat}

{noformat}
  
GPUs

  N/A

{{framework.gpus | number}}
  
{noformat}

> Add support for GPU usage in metrics endpoint
> -
>
> Key: MESOS-5255
> URL: https://issues.apache.org/jira/browse/MESOS-5255
> Project: Mesos
>  Issue Type: Task
>Reporter: Kevin Klues
>Assignee: Kevin Klues
>  Labels: gpu
>
> Currently the usage callback in the Nvidia GPU isolator is unimplemented:
> {noformat}
> src/slave/containerizer/mesos/isolators/cgroups/devices/gpus/nvidia.cpp
> {noformat}
> It should use functionality from NVML to gather the current GPU usage and add 
> it to a ResourceStatistics object. It is still an open question as to exactly 
> what information we want to expose here (power, memory consumption, current 
> load, etc.). Whatever we decide on should be standard across different GPU 
> types, different GPU vendors, etc.



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

[jira] [Created] (MESOS-5255) Add support for GPU usage in metrics endpoint

[Kevin Klues (JIRA)]

Kevin Klues created MESOS-5255:
--

 Summary: Add support for GPU usage in metrics endpoint
 Key: MESOS-5255
 URL: https://issues.apache.org/jira/browse/MESOS-5255
 Project: Mesos
  Issue Type: Task
Reporter: Kevin Klues
Assignee: Kevin Klues


Currently the usage callback in the Nvidia GPU isolator is unimplemented:

{noformat}
src/slave/containerizer/mesos/isolators/cgroups/devices/gpus/nvidia.cpp
{noformat}

It should use functionality from NVML to gather the current GPU usage and add 
it to a ResourceStatistics object. It is still an open question as to exactly 
what information we want to expose here (power, memory consumption, current 
load, etc.). Whatever we decide on should be standard across different GPU 
types, different GPU vendors, etc.



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

[jira] [Comment Edited] (MESOS-3793) Cannot start mesos local on a Debian GNU/Linux 8 docker machine

[Stavros Kontopoulos (JIRA)]

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

Stavros Kontopoulos edited comment on MESOS-3793 at 4/22/16 9:18 PM:
-

Still see the issue with mesos 0.28.1 using this image 
https://hub.docker.com/r/osrg/dind-ubuntu-vivid/
and installing mesos as follows:
{code:|borderStyle=solid}
RUN apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF && \
  DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]') && \
CODENAME=$(lsb_release -cs) && \
echo $CODENAME && \
echo $DISTRO && \
echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | tee 
/etc/apt/sources.list.d/mesosphere.list && \
apt-get -y update && \
VERSION=$(apt-cache madison mesos | head -1 | awk '{ print $3 }')  && \
MARATHON_VERSION=$(apt-cache madison marathon | head -1 | awk '{ print $3 
}') && \
apt-get -y install mesos=$VERSION && \
apt-get install marathon=$MARATHON_VERSION && \
rm -rf /var/lib/apt/lists/*
{code}
When i run:
root@stavrospc:/# /usr/sbin/mesos-slave --master=172.17.0.1:5050 
--ip=172.17.0.1 --launcher=posix
I0422 19:33:32.743777 24201 logging.cpp:188] INFO level logging started!
I0422 19:33:32.743979 24201 main.cpp:223] Build: 2016-04-14 15:43:15 by root
I0422 19:33:32.743996 24201 main.cpp:225] Version: 0.28.1
I0422 19:33:32.744005 24201 main.cpp:228] Git tag: 0.28.1
I0422 19:33:32.744014 24201 main.cpp:232] Git SHA: 
555db235a34afbb9fb49940376cc33a66f1f85f0
I0422 19:33:32.746184 24201 systemd.cpp:236] systemd version `219` detected
I0422 19:33:32.746215 24201 main.cpp:240] Inializing systemd state
Failed to initialize systemd: Failed to locate systemd runtime directory: 
/run/systemd/system
root@stavrospc:/# ls /usr/lib/libm*
/usr/lib/libmesos-0.28.1.so  /usr/lib/libmesos.la  /usr/lib/libmesos.so

Any ideas? 
It is because 15.04 does not use upstart. I verified it by falling back:  
apt-get install  upstart-sysv... then everything worked... but what if i have 
systemd, the flag --launcher...will not work.
With 16.04 that might be an issue...


was (Author: skonto):
Still see the issue with mesos 0.28.1 using this image 
https://hub.docker.com/r/osrg/dind-ubuntu-vivid/
and installing mesos as follows:
{code:|borderStyle=solid}
RUN apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF && \
  DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]') && \
CODENAME=$(lsb_release -cs) && \
echo $CODENAME && \
echo $DISTRO && \
echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | tee 
/etc/apt/sources.list.d/mesosphere.list && \
apt-get -y update && \
VERSION=$(apt-cache madison mesos | head -1 | awk '{ print $3 }')  && \
MARATHON_VERSION=$(apt-cache madison marathon | head -1 | awk '{ print $3 
}') && \
apt-get -y install mesos=$VERSION && \
apt-get install marathon=$MARATHON_VERSION && \
rm -rf /var/lib/apt/lists/*
{code}
When i run:
root@stavrospc:/# /usr/sbin/mesos-slave --master=172.17.0.1:5050 
--ip=172.17.0.1 --launcher=posix
I0422 19:33:32.743777 24201 logging.cpp:188] INFO level logging started!
I0422 19:33:32.743979 24201 main.cpp:223] Build: 2016-04-14 15:43:15 by root
I0422 19:33:32.743996 24201 main.cpp:225] Version: 0.28.1
I0422 19:33:32.744005 24201 main.cpp:228] Git tag: 0.28.1
I0422 19:33:32.744014 24201 main.cpp:232] Git SHA: 
555db235a34afbb9fb49940376cc33a66f1f85f0
I0422 19:33:32.746184 24201 systemd.cpp:236] systemd version `219` detected
I0422 19:33:32.746215 24201 main.cpp:240] Inializing systemd state
Failed to initialize systemd: Failed to locate systemd runtime directory: 
/run/systemd/system
root@stavrospc:/# ls /usr/lib/libm*
/usr/lib/libmesos-0.28.1.so  /usr/lib/libmesos.la  /usr/lib/libmesos.so

Any ideas? 
It is because 15.04 does not use upstart. I verified it by falling back:  
apt-get install  upstart-sysv... then everything worked... but what if i have 
systemd, the flag --launcher...will not work.
With 16.04 that is an issue...

> Cannot start mesos local on a Debian GNU/Linux 8 docker machine
> ---
>
> Key: MESOS-3793
> URL: https://issues.apache.org/jira/browse/MESOS-3793
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.25.0
> Environment: Debian GNU/Linux 8 docker machine
>Reporter: Matthias Veit
>Assignee: Jojy Varghese
>  Labels: mesosphere
> Fix For: 0.26.0
>
>
> We updated the mesos version to 0.25.0 in our Marathon docker image, that 
> runs our integration tests.
> We use mesos local for those tests. This fails with this message:
> {noformat}
> root@a06e4b4eb776:/marathon# mesos local
> I1022 18:42:26.852485   136 leveldb.cpp:176] Opened db in 6.103258ms
> I1022 18:42:26.853302   136 leveldb.cpp:183] Compacted db in 765740ns

[jira] [Commented] (MESOS-5014) Call and Event Type enums in scheduler.proto should be optional

[Vinod Kone (JIRA)]

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

Vinod Kone commented on MESOS-5014:
---

commit 95b7622408fe7580a53dcd6cf5f5424a9c1926cc
Author: Yong Tang 
Date:   Fri Apr 22 13:52:52 2016 -0700

Fixed handling of UNKNOWN Calls and Events in the HTTP API.

This patch is related to:
https://reviews.apache.org/r/45317/ (MESOS-5014)
https://reviews.apache.org/r/45304/ (MESOS-5015)

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


> Call and Event Type enums in scheduler.proto should be optional
> ---
>
> Key: MESOS-5014
> URL: https://issues.apache.org/jira/browse/MESOS-5014
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Vinod Kone
>Assignee: Yong Tang
>  Labels: mesosphere
> Fix For: 0.29.0
>
>
> Having a 'required' Type enum has backwards compatibility issues when adding 
> new enum types. See MESOS-4997 for details.



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

[jira] [Commented] (MESOS-5015) Call and Event Type enums in executor.proto should be optional

[Vinod Kone (JIRA)]

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

Vinod Kone commented on MESOS-5015:
---

commit 95b7622408fe7580a53dcd6cf5f5424a9c1926cc
Author: Yong Tang 
Date:   Fri Apr 22 13:52:52 2016 -0700

Fixed handling of UNKNOWN Calls and Events in the HTTP API.

This patch is related to:
https://reviews.apache.org/r/45317/ (MESOS-5014)
https://reviews.apache.org/r/45304/ (MESOS-5015)

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


> Call and Event Type enums in executor.proto should be optional
> --
>
> Key: MESOS-5015
> URL: https://issues.apache.org/jira/browse/MESOS-5015
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Vinod Kone
>Assignee: Yong Tang
>  Labels: mesosphere
> Fix For: 0.29.0
>
>
> Having a 'required' Type enum has backwards compatibility issues when adding 
> new enum types. See MESOS-4997 for details.



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

[jira] [Commented] (MESOS-5031) Authorization Action enum does not support upgrades.

[Vinod Kone (JIRA)]

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

Vinod Kone commented on MESOS-5031:
---

commit 60dcd72c372b393f06f8917266176f9c86af186b
Author: Yong Tang 
Date:   Fri Apr 22 13:54:28 2016 -0700

Fixed handling of UNKNOWN authorization action.

This patch is related to:
https://reviews.apache.org/r/45342/ (MESOS-5031)

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


> Authorization Action enum does not support upgrades.
> 
>
> Key: MESOS-5031
> URL: https://issues.apache.org/jira/browse/MESOS-5031
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.29.0
>Reporter: Adam B
>Assignee: Yong Tang
>  Labels: mesosphere, security
> Fix For: 0.29.0
>
>
> We need to make the Action enum optional in authorization::Request, and add 
> an `UNKNOWN = 0;` enum value. See MESOS-4997 for details.



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

[jira] [Commented] (MESOS-4678) Upgrade vendored Protobuf to 2.6.1

[Vinod Kone (JIRA)]

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

Vinod Kone commented on MESOS-4678:
---

commit a868b03c931d8d53ea18ca3b41b510d2d03efe94
Author: Benjamin Bannier 
Date:   Fri Apr 22 13:46:43 2016 -0700

Added upstream patch fixing signed/unsigned comparison for protobuf.

This adds the upstream patch \`717f807\` which is contained in
\`protobuf-3.0.0-alpha-1\`. Without this patch compilation with gcc6
fails.

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


> Upgrade vendored Protobuf to 2.6.1
> --
>
> Key: MESOS-4678
> URL: https://issues.apache.org/jira/browse/MESOS-4678
> Project: Mesos
>  Issue Type: Improvement
>  Components: general
>Reporter: Neil Conway
>Assignee: Chen Zhiwei
>  Labels: 3rdParty, mesosphere, protobuf, tech-debt
> Fix For: 0.29.0
>
>
> We currently vendor Protobuf 2.5.0. We should upgrade to Protobuf 2.6.1. This 
> introduces various bugfixes, performance improvements, and at least one new 
> feature we might want to eventually take advantage of ({{map}} data type). 
> AFAIK there should be no backward compatibility concerns.



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

[jira] [Comment Edited] (MESOS-3793) Cannot start mesos local on a Debian GNU/Linux 8 docker machine

[Stavros Kontopoulos (JIRA)]

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

Stavros Kontopoulos edited comment on MESOS-3793 at 4/22/16 8:09 PM:
-

Still see the issue with mesos 0.28.1 using this image 
https://hub.docker.com/r/osrg/dind-ubuntu-vivid/
and installing mesos as follows:
{code:|borderStyle=solid}
RUN apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF && \
  DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]') && \
CODENAME=$(lsb_release -cs) && \
echo $CODENAME && \
echo $DISTRO && \
echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | tee 
/etc/apt/sources.list.d/mesosphere.list && \
apt-get -y update && \
VERSION=$(apt-cache madison mesos | head -1 | awk '{ print $3 }')  && \
MARATHON_VERSION=$(apt-cache madison marathon | head -1 | awk '{ print $3 
}') && \
apt-get -y install mesos=$VERSION && \
apt-get install marathon=$MARATHON_VERSION && \
rm -rf /var/lib/apt/lists/*
{code}
When i run:
root@stavrospc:/# /usr/sbin/mesos-slave --master=172.17.0.1:5050 
--ip=172.17.0.1 --launcher=posix
I0422 19:33:32.743777 24201 logging.cpp:188] INFO level logging started!
I0422 19:33:32.743979 24201 main.cpp:223] Build: 2016-04-14 15:43:15 by root
I0422 19:33:32.743996 24201 main.cpp:225] Version: 0.28.1
I0422 19:33:32.744005 24201 main.cpp:228] Git tag: 0.28.1
I0422 19:33:32.744014 24201 main.cpp:232] Git SHA: 
555db235a34afbb9fb49940376cc33a66f1f85f0
I0422 19:33:32.746184 24201 systemd.cpp:236] systemd version `219` detected
I0422 19:33:32.746215 24201 main.cpp:240] Inializing systemd state
Failed to initialize systemd: Failed to locate systemd runtime directory: 
/run/systemd/system
root@stavrospc:/# ls /usr/lib/libm*
/usr/lib/libmesos-0.28.1.so  /usr/lib/libmesos.la  /usr/lib/libmesos.so

Any ideas? 
It is because 15.04 does not use upstart. I verified it by falling back:  
apt-get install  upstart-sysv... then everything worked... but what if i have 
systemd, the flag --launcher...will not work
and with 16.04 that is an issue...


was (Author: skonto):
Still see the issue with mesos 0.28.1 using this image 
https://hub.docker.com/r/osrg/dind-ubuntu-vivid/
and installing mesos as follows:
{code:|borderStyle=solid}
RUN apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF && \
  DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]') && \
CODENAME=$(lsb_release -cs) && \
echo $CODENAME && \
echo $DISTRO && \
echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | tee 
/etc/apt/sources.list.d/mesosphere.list && \
apt-get -y update && \
VERSION=$(apt-cache madison mesos | head -1 | awk '{ print $3 }')  && \
MARATHON_VERSION=$(apt-cache madison marathon | head -1 | awk '{ print $3 
}') && \
apt-get -y install mesos=$VERSION && \
apt-get install marathon=$MARATHON_VERSION && \
rm -rf /var/lib/apt/lists/*
{code}
When i run:
root@stavrospc:/# /usr/sbin/mesos-slave --master=172.17.0.1:5050 
--ip=172.17.0.1 --launcher=posix
I0422 19:33:32.743777 24201 logging.cpp:188] INFO level logging started!
I0422 19:33:32.743979 24201 main.cpp:223] Build: 2016-04-14 15:43:15 by root
I0422 19:33:32.743996 24201 main.cpp:225] Version: 0.28.1
I0422 19:33:32.744005 24201 main.cpp:228] Git tag: 0.28.1
I0422 19:33:32.744014 24201 main.cpp:232] Git SHA: 
555db235a34afbb9fb49940376cc33a66f1f85f0
I0422 19:33:32.746184 24201 systemd.cpp:236] systemd version `219` detected
I0422 19:33:32.746215 24201 main.cpp:240] Inializing systemd state
Failed to initialize systemd: Failed to locate systemd runtime directory: 
/run/systemd/system
root@stavrospc:/# ls /usr/lib/libm*
/usr/lib/libmesos-0.28.1.so  /usr/lib/libmesos.la  /usr/lib/libmesos.so

Any ideas? 
It is because 15.04 does not use upstart. I verified it by falling back:  
apt-get install  upstart-sysv... then everything worked... but the what if i 
have systemd the flag --launcher...does not work



> Cannot start mesos local on a Debian GNU/Linux 8 docker machine
> ---
>
> Key: MESOS-3793
> URL: https://issues.apache.org/jira/browse/MESOS-3793
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.25.0
> Environment: Debian GNU/Linux 8 docker machine
>Reporter: Matthias Veit
>Assignee: Jojy Varghese
>  Labels: mesosphere
> Fix For: 0.26.0
>
>
> We updated the mesos version to 0.25.0 in our Marathon docker image, that 
> runs our integration tests.
> We use mesos local for those tests. This fails with this message:
> {noformat}
> root@a06e4b4eb776:/marathon# mesos local
> I1022 18:42:26.852485   136 leveldb.cpp:176] Opened db in 6.103258ms
> I1022 18:42:26.853302   136 leveldb.cpp:183] Compacted db in 765740ns
> I1022 

[jira] [Comment Edited] (MESOS-3793) Cannot start mesos local on a Debian GNU/Linux 8 docker machine

[Stavros Kontopoulos (JIRA)]

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

Stavros Kontopoulos edited comment on MESOS-3793 at 4/22/16 8:09 PM:
-

Still see the issue with mesos 0.28.1 using this image 
https://hub.docker.com/r/osrg/dind-ubuntu-vivid/
and installing mesos as follows:
{code:|borderStyle=solid}
RUN apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF && \
  DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]') && \
CODENAME=$(lsb_release -cs) && \
echo $CODENAME && \
echo $DISTRO && \
echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | tee 
/etc/apt/sources.list.d/mesosphere.list && \
apt-get -y update && \
VERSION=$(apt-cache madison mesos | head -1 | awk '{ print $3 }')  && \
MARATHON_VERSION=$(apt-cache madison marathon | head -1 | awk '{ print $3 
}') && \
apt-get -y install mesos=$VERSION && \
apt-get install marathon=$MARATHON_VERSION && \
rm -rf /var/lib/apt/lists/*
{code}
When i run:
root@stavrospc:/# /usr/sbin/mesos-slave --master=172.17.0.1:5050 
--ip=172.17.0.1 --launcher=posix
I0422 19:33:32.743777 24201 logging.cpp:188] INFO level logging started!
I0422 19:33:32.743979 24201 main.cpp:223] Build: 2016-04-14 15:43:15 by root
I0422 19:33:32.743996 24201 main.cpp:225] Version: 0.28.1
I0422 19:33:32.744005 24201 main.cpp:228] Git tag: 0.28.1
I0422 19:33:32.744014 24201 main.cpp:232] Git SHA: 
555db235a34afbb9fb49940376cc33a66f1f85f0
I0422 19:33:32.746184 24201 systemd.cpp:236] systemd version `219` detected
I0422 19:33:32.746215 24201 main.cpp:240] Inializing systemd state
Failed to initialize systemd: Failed to locate systemd runtime directory: 
/run/systemd/system
root@stavrospc:/# ls /usr/lib/libm*
/usr/lib/libmesos-0.28.1.so  /usr/lib/libmesos.la  /usr/lib/libmesos.so

Any ideas? 
It is because 15.04 does not use upstart. I verified it by falling back:  
apt-get install  upstart-sysv... then everything worked... but what if i have 
systemd, the flag --launcher...will not work.
With 16.04 that is an issue...


was (Author: skonto):
Still see the issue with mesos 0.28.1 using this image 
https://hub.docker.com/r/osrg/dind-ubuntu-vivid/
and installing mesos as follows:
{code:|borderStyle=solid}
RUN apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF && \
  DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]') && \
CODENAME=$(lsb_release -cs) && \
echo $CODENAME && \
echo $DISTRO && \
echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | tee 
/etc/apt/sources.list.d/mesosphere.list && \
apt-get -y update && \
VERSION=$(apt-cache madison mesos | head -1 | awk '{ print $3 }')  && \
MARATHON_VERSION=$(apt-cache madison marathon | head -1 | awk '{ print $3 
}') && \
apt-get -y install mesos=$VERSION && \
apt-get install marathon=$MARATHON_VERSION && \
rm -rf /var/lib/apt/lists/*
{code}
When i run:
root@stavrospc:/# /usr/sbin/mesos-slave --master=172.17.0.1:5050 
--ip=172.17.0.1 --launcher=posix
I0422 19:33:32.743777 24201 logging.cpp:188] INFO level logging started!
I0422 19:33:32.743979 24201 main.cpp:223] Build: 2016-04-14 15:43:15 by root
I0422 19:33:32.743996 24201 main.cpp:225] Version: 0.28.1
I0422 19:33:32.744005 24201 main.cpp:228] Git tag: 0.28.1
I0422 19:33:32.744014 24201 main.cpp:232] Git SHA: 
555db235a34afbb9fb49940376cc33a66f1f85f0
I0422 19:33:32.746184 24201 systemd.cpp:236] systemd version `219` detected
I0422 19:33:32.746215 24201 main.cpp:240] Inializing systemd state
Failed to initialize systemd: Failed to locate systemd runtime directory: 
/run/systemd/system
root@stavrospc:/# ls /usr/lib/libm*
/usr/lib/libmesos-0.28.1.so  /usr/lib/libmesos.la  /usr/lib/libmesos.so

Any ideas? 
It is because 15.04 does not use upstart. I verified it by falling back:  
apt-get install  upstart-sysv... then everything worked... but what if i have 
systemd, the flag --launcher...will not work
and with 16.04 that is an issue...

> Cannot start mesos local on a Debian GNU/Linux 8 docker machine
> ---
>
> Key: MESOS-3793
> URL: https://issues.apache.org/jira/browse/MESOS-3793
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.25.0
> Environment: Debian GNU/Linux 8 docker machine
>Reporter: Matthias Veit
>Assignee: Jojy Varghese
>  Labels: mesosphere
> Fix For: 0.26.0
>
>
> We updated the mesos version to 0.25.0 in our Marathon docker image, that 
> runs our integration tests.
> We use mesos local for those tests. This fails with this message:
> {noformat}
> root@a06e4b4eb776:/marathon# mesos local
> I1022 18:42:26.852485   136 leveldb.cpp:176] Opened db in 6.103258ms
> I1022 18:42:26.853302   136 leveldb.cpp:183] Compacted db in 765740ns

[jira] [Comment Edited] (MESOS-3793) Cannot start mesos local on a Debian GNU/Linux 8 docker machine

[Stavros Kontopoulos (JIRA)]

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

Stavros Kontopoulos edited comment on MESOS-3793 at 4/22/16 8:08 PM:
-

Still see the issue with mesos 0.28.1 using this image 
https://hub.docker.com/r/osrg/dind-ubuntu-vivid/
and installing mesos as follows:
{code:|borderStyle=solid}
RUN apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF && \
  DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]') && \
CODENAME=$(lsb_release -cs) && \
echo $CODENAME && \
echo $DISTRO && \
echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | tee 
/etc/apt/sources.list.d/mesosphere.list && \
apt-get -y update && \
VERSION=$(apt-cache madison mesos | head -1 | awk '{ print $3 }')  && \
MARATHON_VERSION=$(apt-cache madison marathon | head -1 | awk '{ print $3 
}') && \
apt-get -y install mesos=$VERSION && \
apt-get install marathon=$MARATHON_VERSION && \
rm -rf /var/lib/apt/lists/*
{code}
When i run:
root@stavrospc:/# /usr/sbin/mesos-slave --master=172.17.0.1:5050 
--ip=172.17.0.1 --launcher=posix
I0422 19:33:32.743777 24201 logging.cpp:188] INFO level logging started!
I0422 19:33:32.743979 24201 main.cpp:223] Build: 2016-04-14 15:43:15 by root
I0422 19:33:32.743996 24201 main.cpp:225] Version: 0.28.1
I0422 19:33:32.744005 24201 main.cpp:228] Git tag: 0.28.1
I0422 19:33:32.744014 24201 main.cpp:232] Git SHA: 
555db235a34afbb9fb49940376cc33a66f1f85f0
I0422 19:33:32.746184 24201 systemd.cpp:236] systemd version `219` detected
I0422 19:33:32.746215 24201 main.cpp:240] Inializing systemd state
Failed to initialize systemd: Failed to locate systemd runtime directory: 
/run/systemd/system
root@stavrospc:/# ls /usr/lib/libm*
/usr/lib/libmesos-0.28.1.so  /usr/lib/libmesos.la  /usr/lib/libmesos.so

Any ideas? 
It is because 15.04 does not use upstart. I verified it by falling back:  
apt-get install  upstart-sysv... then everything worked... but the what if i 
have systemd the flag --launcher...does not work




was (Author: skonto):
Still see the issue with mesos 0.28.1 using this image 
https://hub.docker.com/r/osrg/dind-ubuntu-vivid/
and installing mesos as follows:
{code:|borderStyle=solid}
RUN apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF && \
  DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]') && \
CODENAME=$(lsb_release -cs) && \
echo $CODENAME && \
echo $DISTRO && \
echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | tee 
/etc/apt/sources.list.d/mesosphere.list && \
apt-get -y update && \
VERSION=$(apt-cache madison mesos | head -1 | awk '{ print $3 }')  && \
MARATHON_VERSION=$(apt-cache madison marathon | head -1 | awk '{ print $3 
}') && \
apt-get -y install mesos=$VERSION && \
apt-get install marathon=$MARATHON_VERSION && \
rm -rf /var/lib/apt/lists/*
{code}
When i run:
root@stavrospc:/# /usr/sbin/mesos-slave --master=172.17.0.1:5050 
--ip=172.17.0.1 --launcher=posix
I0422 19:33:32.743777 24201 logging.cpp:188] INFO level logging started!
I0422 19:33:32.743979 24201 main.cpp:223] Build: 2016-04-14 15:43:15 by root
I0422 19:33:32.743996 24201 main.cpp:225] Version: 0.28.1
I0422 19:33:32.744005 24201 main.cpp:228] Git tag: 0.28.1
I0422 19:33:32.744014 24201 main.cpp:232] Git SHA: 
555db235a34afbb9fb49940376cc33a66f1f85f0
I0422 19:33:32.746184 24201 systemd.cpp:236] systemd version `219` detected
I0422 19:33:32.746215 24201 main.cpp:240] Inializing systemd state
Failed to initialize systemd: Failed to locate systemd runtime directory: 
/run/systemd/system
root@stavrospc:/# ls /usr/lib/libm*
/usr/lib/libmesos-0.28.1.so  /usr/lib/libmesos.la  /usr/lib/libmesos.so

Any ideas? Is it because 15.04 does not use upstart?


> Cannot start mesos local on a Debian GNU/Linux 8 docker machine
> ---
>
> Key: MESOS-3793
> URL: https://issues.apache.org/jira/browse/MESOS-3793
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.25.0
> Environment: Debian GNU/Linux 8 docker machine
>Reporter: Matthias Veit
>Assignee: Jojy Varghese
>  Labels: mesosphere
> Fix For: 0.26.0
>
>
> We updated the mesos version to 0.25.0 in our Marathon docker image, that 
> runs our integration tests.
> We use mesos local for those tests. This fails with this message:
> {noformat}
> root@a06e4b4eb776:/marathon# mesos local
> I1022 18:42:26.852485   136 leveldb.cpp:176] Opened db in 6.103258ms
> I1022 18:42:26.853302   136 leveldb.cpp:183] Compacted db in 765740ns
> I1022 18:42:26.853343   136 leveldb.cpp:198] Created db iterator in 9001ns
> I1022 18:42:26.853355   136 leveldb.cpp:204] Seeked to beginning of db in 
> 1287ns
> I1022 18:42:26.853366   136 leveldb.cpp:273] Iterated 

[jira] [Comment Edited] (MESOS-3793) Cannot start mesos local on a Debian GNU/Linux 8 docker machine

[Stavros Kontopoulos (JIRA)]

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

Stavros Kontopoulos edited comment on MESOS-3793 at 4/22/16 8:06 PM:
-

Still see the issue with mesos 0.28.1 using this image 
https://hub.docker.com/r/osrg/dind-ubuntu-vivid/
and installing mesos as follows:
{code:|borderStyle=solid}
RUN apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF && \
  DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]') && \
CODENAME=$(lsb_release -cs) && \
echo $CODENAME && \
echo $DISTRO && \
echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | tee 
/etc/apt/sources.list.d/mesosphere.list && \
apt-get -y update && \
VERSION=$(apt-cache madison mesos | head -1 | awk '{ print $3 }')  && \
MARATHON_VERSION=$(apt-cache madison marathon | head -1 | awk '{ print $3 
}') && \
apt-get -y install mesos=$VERSION && \
apt-get install marathon=$MARATHON_VERSION && \
rm -rf /var/lib/apt/lists/*
{code}
When i run:
root@stavrospc:/# /usr/sbin/mesos-slave --master=172.17.0.1:5050 
--ip=172.17.0.1 --launcher=posix
I0422 19:33:32.743777 24201 logging.cpp:188] INFO level logging started!
I0422 19:33:32.743979 24201 main.cpp:223] Build: 2016-04-14 15:43:15 by root
I0422 19:33:32.743996 24201 main.cpp:225] Version: 0.28.1
I0422 19:33:32.744005 24201 main.cpp:228] Git tag: 0.28.1
I0422 19:33:32.744014 24201 main.cpp:232] Git SHA: 
555db235a34afbb9fb49940376cc33a66f1f85f0
I0422 19:33:32.746184 24201 systemd.cpp:236] systemd version `219` detected
I0422 19:33:32.746215 24201 main.cpp:240] Inializing systemd state
Failed to initialize systemd: Failed to locate systemd runtime directory: 
/run/systemd/system
root@stavrospc:/# ls /usr/lib/libm*
/usr/lib/libmesos-0.28.1.so  /usr/lib/libmesos.la  /usr/lib/libmesos.so

Any ideas? Is it because 15.04 does not use upstart?



was (Author: skonto):
Still see the issue with mesos 0.28.1 using this image 
https://hub.docker.com/r/osrg/dind-ubuntu-vivid/
and installing mesos as follows:
{code:|borderStyle=solid}
RUN apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF && \
  DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]') && \
CODENAME=$(lsb_release -cs) && \
echo $CODENAME && \
echo $DISTRO && \
echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | tee 
/etc/apt/sources.list.d/mesosphere.list && \
apt-get -y update && \
VERSION=$(apt-cache madison mesos | head -1 | awk '{ print $3 }')  && \
MARATHON_VERSION=$(apt-cache madison marathon | head -1 | awk '{ print $3 
}') && \
apt-get -y install mesos=$VERSION && \
apt-get install marathon=$MARATHON_VERSION && \
rm -rf /var/lib/apt/lists/*
{code}
When i run:
root@stavrospc:/# /usr/sbin/mesos-slave --master=172.17.0.1:5050 
--ip=172.17.0.1 --launcher=posix
I0422 19:33:32.743777 24201 logging.cpp:188] INFO level logging started!
I0422 19:33:32.743979 24201 main.cpp:223] Build: 2016-04-14 15:43:15 by root
I0422 19:33:32.743996 24201 main.cpp:225] Version: 0.28.1
I0422 19:33:32.744005 24201 main.cpp:228] Git tag: 0.28.1
I0422 19:33:32.744014 24201 main.cpp:232] Git SHA: 
555db235a34afbb9fb49940376cc33a66f1f85f0
I0422 19:33:32.746184 24201 systemd.cpp:236] systemd version `219` detected
I0422 19:33:32.746215 24201 main.cpp:240] Inializing systemd state
Failed to initialize systemd: Failed to locate systemd runtime directory: 
/run/systemd/system
root@stavrospc:/# ls /usr/lib/libm*
/usr/lib/libmesos-0.28.1.so  /usr/lib/libmesos.la  /usr/lib/libmesos.so

Any ideas?



> Cannot start mesos local on a Debian GNU/Linux 8 docker machine
> ---
>
> Key: MESOS-3793
> URL: https://issues.apache.org/jira/browse/MESOS-3793
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.25.0
> Environment: Debian GNU/Linux 8 docker machine
>Reporter: Matthias Veit
>Assignee: Jojy Varghese
>  Labels: mesosphere
> Fix For: 0.26.0
>
>
> We updated the mesos version to 0.25.0 in our Marathon docker image, that 
> runs our integration tests.
> We use mesos local for those tests. This fails with this message:
> {noformat}
> root@a06e4b4eb776:/marathon# mesos local
> I1022 18:42:26.852485   136 leveldb.cpp:176] Opened db in 6.103258ms
> I1022 18:42:26.853302   136 leveldb.cpp:183] Compacted db in 765740ns
> I1022 18:42:26.853343   136 leveldb.cpp:198] Created db iterator in 9001ns
> I1022 18:42:26.853355   136 leveldb.cpp:204] Seeked to beginning of db in 
> 1287ns
> I1022 18:42:26.853366   136 leveldb.cpp:273] Iterated through 0 keys in the 
> db in ns
> I1022 18:42:26.853406   136 replica.cpp:744] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1022 18:42:26.853775   141 

[jira] [Commented] (MESOS-4543) Mesos slave in docker fails with Mesos >= 0.25.0

[Stavros Kontopoulos (JIRA)]

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

Stavros Kontopoulos commented on MESOS-4543:


i see the same issue and the extra parameter does not solve it see: 
https://issues.apache.org/jira/browse/MESOS-3793


> Mesos slave in docker fails with Mesos >= 0.25.0 
> -
>
> Key: MESOS-4543
> URL: https://issues.apache.org/jira/browse/MESOS-4543
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.25.0
>Reporter: Giulio Eulisse
>
> I've a mesos in docker setup which works quite nicely with mesos 0.24.0. I am 
> now trying to move to a newer mesos and I get:
> {code}
> slave_1 | + mesos-slave --master=zk://localhost:2181/mesos 
> --work_dir=/var/lib/mesos --containerizers=docker,mesos
> slave_1 | I0128 14:00:13.759659  6904 main.cpp:185] Build: 2015-10-12 
> 20:59:01 by root
> slave_1 | I0128 14:00:13.759711  6904 main.cpp:187] Version: 0.25.0
> slave_1 | I0128 14:00:13.759713  6904 main.cpp:190] Git tag: 0.25.0
> slave_1 | I0128 14:00:13.759716  6904 main.cpp:194] Git SHA: 
> 2dd7f7ee115fe00b8e098b0a10762a4fa8f4600f
> slave_1 | I0128 14:00:13.864392  6904 containerizer.cpp:143] Using isolation: 
> posix/cpu,posix/mem,filesystem/posix
> slave_1 | I0128 14:00:13.871894  6904 linux_launcher.cpp:103] Using 
> /sys/fs/cgroup/freezer as the freezer hierarchy for the Linux launcher
> slave_1 | I0128 14:00:13.881038  6904 systemd.cpp:128] systemd version `219` 
> detected
> slave_1 | Failed to create a containerizer: Could not create 
> MesosContainerizer: Failed to create launcher: Failed to initialize systemd: 
> Failed to locate systemd runtime directory: /run/systemd/system
> {code}
> You can reproduce this by doing:
> {code}
> git clone https://github.com/ktf/ali-bot
> cd ali-bot
> docker-compose up slave
> {code}
> I think this is related to the recent changes to accomodate better 
> integration with systemd. Any idea what I'm missing? I am running this using 
> boot2docker.



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

[jira] [Comment Edited] (MESOS-3793) Cannot start mesos local on a Debian GNU/Linux 8 docker machine

[Stavros Kontopoulos (JIRA)]

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

Stavros Kontopoulos edited comment on MESOS-3793 at 4/22/16 7:54 PM:
-

Still see the issue with mesos 0.28.1 using this image 
https://hub.docker.com/r/osrg/dind-ubuntu-vivid/
and installing mesos as follows:
{code:|borderStyle=solid}
RUN apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF && \
  DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]') && \
CODENAME=$(lsb_release -cs) && \
echo $CODENAME && \
echo $DISTRO && \
echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | tee 
/etc/apt/sources.list.d/mesosphere.list && \
apt-get -y update && \
VERSION=$(apt-cache madison mesos | head -1 | awk '{ print $3 }')  && \
MARATHON_VERSION=$(apt-cache madison marathon | head -1 | awk '{ print $3 
}') && \
apt-get -y install mesos=$VERSION && \
apt-get install marathon=$MARATHON_VERSION && \
rm -rf /var/lib/apt/lists/*
{code}
When i run:
root@stavrospc:/# /usr/sbin/mesos-slave --master=172.17.0.1:5050 
--ip=172.17.0.1 --launcher=posix
I0422 19:33:32.743777 24201 logging.cpp:188] INFO level logging started!
I0422 19:33:32.743979 24201 main.cpp:223] Build: 2016-04-14 15:43:15 by root
I0422 19:33:32.743996 24201 main.cpp:225] Version: 0.28.1
I0422 19:33:32.744005 24201 main.cpp:228] Git tag: 0.28.1
I0422 19:33:32.744014 24201 main.cpp:232] Git SHA: 
555db235a34afbb9fb49940376cc33a66f1f85f0
I0422 19:33:32.746184 24201 systemd.cpp:236] systemd version `219` detected
I0422 19:33:32.746215 24201 main.cpp:240] Inializing systemd state
Failed to initialize systemd: Failed to locate systemd runtime directory: 
/run/systemd/system
root@stavrospc:/# ls /usr/lib/libm*
/usr/lib/libmesos-0.28.1.so  /usr/lib/libmesos.la  /usr/lib/libmesos.so

Any ideas?




was (Author: skonto):
Still see the issue with mesos 0.28.1 using this image 
https://hub.docker.com/r/osrg/dind-ubuntu-vivid/
and installing mesos as follows:
{code:|borderStyle=solid}
RUN apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF && \
  DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]') && \
CODENAME=$(lsb_release -cs) && \
echo $CODENAME && \
echo $DISTRO && \
echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | tee 
/etc/apt/sources.list.d/mesosphere.list && \
apt-get -y update && \
VERSION=$(apt-cache madison mesos | head -1 | awk '{ print $3 }')  && \
MARATHON_VERSION=$(apt-cache madison marathon | head -1 | awk '{ print $3 
}') && \
apt-get -y install mesos=$VERSION && \
apt-get install marathon=$MARATHON_VERSION && \
rm -rf /var/lib/apt/lists/*

{code}
When i run:
root@stavrospc:/# /usr/sbin/mesos-slave --master=172.17.0.1:5050 
--ip=172.17.0.1 --launcher=posix
I0422 19:33:32.743777 24201 logging.cpp:188] INFO level logging started!
I0422 19:33:32.743979 24201 main.cpp:223] Build: 2016-04-14 15:43:15 by root
I0422 19:33:32.743996 24201 main.cpp:225] Version: 0.28.1
I0422 19:33:32.744005 24201 main.cpp:228] Git tag: 0.28.1
I0422 19:33:32.744014 24201 main.cpp:232] Git SHA: 
555db235a34afbb9fb49940376cc33a66f1f85f0
I0422 19:33:32.746184 24201 systemd.cpp:236] systemd version `219` detected
I0422 19:33:32.746215 24201 main.cpp:240] Inializing systemd state
Failed to initialize systemd: Failed to locate systemd runtime directory: 
/run/systemd/system
root@stavrospc:/# ls /usr/lib/libm*
/usr/lib/libmesos-0.28.1.so  /usr/lib/libmesos.la  /usr/lib/libmesos.so

Any ideas?



> Cannot start mesos local on a Debian GNU/Linux 8 docker machine
> ---
>
> Key: MESOS-3793
> URL: https://issues.apache.org/jira/browse/MESOS-3793
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.25.0
> Environment: Debian GNU/Linux 8 docker machine
>Reporter: Matthias Veit
>Assignee: Jojy Varghese
>  Labels: mesosphere
> Fix For: 0.26.0
>
>
> We updated the mesos version to 0.25.0 in our Marathon docker image, that 
> runs our integration tests.
> We use mesos local for those tests. This fails with this message:
> {noformat}
> root@a06e4b4eb776:/marathon# mesos local
> I1022 18:42:26.852485   136 leveldb.cpp:176] Opened db in 6.103258ms
> I1022 18:42:26.853302   136 leveldb.cpp:183] Compacted db in 765740ns
> I1022 18:42:26.853343   136 leveldb.cpp:198] Created db iterator in 9001ns
> I1022 18:42:26.853355   136 leveldb.cpp:204] Seeked to beginning of db in 
> 1287ns
> I1022 18:42:26.853366   136 leveldb.cpp:273] Iterated through 0 keys in the 
> db in ns
> I1022 18:42:26.853406   136 replica.cpp:744] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1022 18:42:26.853775   141 recover.cpp:449] Starting replica recovery
> I1022 

[jira] [Comment Edited] (MESOS-3793) Cannot start mesos local on a Debian GNU/Linux 8 docker machine

[Stavros Kontopoulos (JIRA)]

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

Stavros Kontopoulos edited comment on MESOS-3793 at 4/22/16 7:54 PM:
-

Still see the issue with mesos 0.28.1 using this image 
https://hub.docker.com/r/osrg/dind-ubuntu-vivid/
and installing mesos as follows:
{code:|borderStyle=solid}
RUN apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF && \
  DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]') && \
CODENAME=$(lsb_release -cs) && \
echo $CODENAME && \
echo $DISTRO && \
echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | tee 
/etc/apt/sources.list.d/mesosphere.list && \
apt-get -y update && \
VERSION=$(apt-cache madison mesos | head -1 | awk '{ print $3 }')  && \
MARATHON_VERSION=$(apt-cache madison marathon | head -1 | awk '{ print $3 
}') && \
apt-get -y install mesos=$VERSION && \
apt-get install marathon=$MARATHON_VERSION && \
rm -rf /var/lib/apt/lists/*

{code}
When i run:
root@stavrospc:/# /usr/sbin/mesos-slave --master=172.17.0.1:5050 
--ip=172.17.0.1 --launcher=posix
I0422 19:33:32.743777 24201 logging.cpp:188] INFO level logging started!
I0422 19:33:32.743979 24201 main.cpp:223] Build: 2016-04-14 15:43:15 by root
I0422 19:33:32.743996 24201 main.cpp:225] Version: 0.28.1
I0422 19:33:32.744005 24201 main.cpp:228] Git tag: 0.28.1
I0422 19:33:32.744014 24201 main.cpp:232] Git SHA: 
555db235a34afbb9fb49940376cc33a66f1f85f0
I0422 19:33:32.746184 24201 systemd.cpp:236] systemd version `219` detected
I0422 19:33:32.746215 24201 main.cpp:240] Inializing systemd state
Failed to initialize systemd: Failed to locate systemd runtime directory: 
/run/systemd/system
root@stavrospc:/# ls /usr/lib/libm*
/usr/lib/libmesos-0.28.1.so  /usr/lib/libmesos.la  /usr/lib/libmesos.so

Any ideas?




was (Author: skonto):
Still see the issue with mesos 0.28.1 using this image 
https://hub.docker.com/r/osrg/dind-ubuntu-vivid/
and installing mesos as follows:
RUN apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF && \
  DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]') && \
CODENAME=$(lsb_release -cs) && \
echo $CODENAME && \
echo $DISTRO && \
echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | tee 
/etc/apt/sources.list.d/mesosphere.list && \
apt-get -y update && \
VERSION=$(apt-cache madison mesos | head -1 | awk '{ print $3 }')  && \
MARATHON_VERSION=$(apt-cache madison marathon | head -1 | awk '{ print $3 
}') && \
apt-get -y install mesos=$VERSION && \
apt-get install marathon=$MARATHON_VERSION && \
rm -rf /var/lib/apt/lists/*

When i run:
root@stavrospc:/# /usr/sbin/mesos-slave --master=172.17.0.1:5050 
--ip=172.17.0.1 --launcher=posix
I0422 19:33:32.743777 24201 logging.cpp:188] INFO level logging started!
I0422 19:33:32.743979 24201 main.cpp:223] Build: 2016-04-14 15:43:15 by root
I0422 19:33:32.743996 24201 main.cpp:225] Version: 0.28.1
I0422 19:33:32.744005 24201 main.cpp:228] Git tag: 0.28.1
I0422 19:33:32.744014 24201 main.cpp:232] Git SHA: 
555db235a34afbb9fb49940376cc33a66f1f85f0
I0422 19:33:32.746184 24201 systemd.cpp:236] systemd version `219` detected
I0422 19:33:32.746215 24201 main.cpp:240] Inializing systemd state
Failed to initialize systemd: Failed to locate systemd runtime directory: 
/run/systemd/system
root@stavrospc:/# ls /usr/lib/libm*
/usr/lib/libmesos-0.28.1.so  /usr/lib/libmesos.la  /usr/lib/libmesos.so

Any ideas?



> Cannot start mesos local on a Debian GNU/Linux 8 docker machine
> ---
>
> Key: MESOS-3793
> URL: https://issues.apache.org/jira/browse/MESOS-3793
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.25.0
> Environment: Debian GNU/Linux 8 docker machine
>Reporter: Matthias Veit
>Assignee: Jojy Varghese
>  Labels: mesosphere
> Fix For: 0.26.0
>
>
> We updated the mesos version to 0.25.0 in our Marathon docker image, that 
> runs our integration tests.
> We use mesos local for those tests. This fails with this message:
> {noformat}
> root@a06e4b4eb776:/marathon# mesos local
> I1022 18:42:26.852485   136 leveldb.cpp:176] Opened db in 6.103258ms
> I1022 18:42:26.853302   136 leveldb.cpp:183] Compacted db in 765740ns
> I1022 18:42:26.853343   136 leveldb.cpp:198] Created db iterator in 9001ns
> I1022 18:42:26.853355   136 leveldb.cpp:204] Seeked to beginning of db in 
> 1287ns
> I1022 18:42:26.853366   136 leveldb.cpp:273] Iterated through 0 keys in the 
> db in ns
> I1022 18:42:26.853406   136 replica.cpp:744] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1022 18:42:26.853775   141 recover.cpp:449] Starting replica recovery
> I1022 18:42:26.853862   141 

[jira] [Comment Edited] (MESOS-3793) Cannot start mesos local on a Debian GNU/Linux 8 docker machine

[Stavros Kontopoulos (JIRA)]

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

Stavros Kontopoulos edited comment on MESOS-3793 at 4/22/16 7:34 PM:
-

Still see the issue with mesos 0.28.1 using this image 
https://hub.docker.com/r/osrg/dind-ubuntu-vivid/
and installing mesos as follows:
RUN apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF && \
  DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]') && \
CODENAME=$(lsb_release -cs) && \
echo $CODENAME && \
echo $DISTRO && \
echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | tee 
/etc/apt/sources.list.d/mesosphere.list && \
apt-get -y update && \
VERSION=$(apt-cache madison mesos | head -1 | awk '{ print $3 }')  && \
MARATHON_VERSION=$(apt-cache madison marathon | head -1 | awk '{ print $3 
}') && \
apt-get -y install mesos=$VERSION && \
apt-get install marathon=$MARATHON_VERSION && \
rm -rf /var/lib/apt/lists/*

When i run:
root@stavrospc:/# /usr/sbin/mesos-slave --master=172.17.0.1:5050 
--ip=172.17.0.1 --launcher=posix
I0422 19:33:32.743777 24201 logging.cpp:188] INFO level logging started!
I0422 19:33:32.743979 24201 main.cpp:223] Build: 2016-04-14 15:43:15 by root
I0422 19:33:32.743996 24201 main.cpp:225] Version: 0.28.1
I0422 19:33:32.744005 24201 main.cpp:228] Git tag: 0.28.1
I0422 19:33:32.744014 24201 main.cpp:232] Git SHA: 
555db235a34afbb9fb49940376cc33a66f1f85f0
I0422 19:33:32.746184 24201 systemd.cpp:236] systemd version `219` detected
I0422 19:33:32.746215 24201 main.cpp:240] Inializing systemd state
Failed to initialize systemd: Failed to locate systemd runtime directory: 
/run/systemd/system
root@stavrospc:/# ls /usr/lib/libm*
/usr/lib/libmesos-0.28.1.so  /usr/lib/libmesos.la  /usr/lib/libmesos.so

Any ideas?




was (Author: skonto):
Still see the issue with mesos 0.28.1 using this images 
https://hub.docker.com/r/osrg/dind-ubuntu-vivid/
and installing mesos as follows:
RUN apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF && \
  DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]') && \
CODENAME=$(lsb_release -cs) && \
echo $CODENAME && \
echo $DISTRO && \
echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | tee 
/etc/apt/sources.list.d/mesosphere.list && \
apt-get -y update && \
VERSION=$(apt-cache madison mesos | head -1 | awk '{ print $3 }')  && \
MARATHON_VERSION=$(apt-cache madison marathon | head -1 | awk '{ print $3 
}') && \
apt-get -y install mesos=$VERSION && \
apt-get install marathon=$MARATHON_VERSION && \
rm -rf /var/lib/apt/lists/*

When i run:
root@stavrospc:/# /usr/sbin/mesos-slave --master=172.17.0.1:5050 
--ip=172.17.0.1 --launcher=posix
I0422 19:33:32.743777 24201 logging.cpp:188] INFO level logging started!
I0422 19:33:32.743979 24201 main.cpp:223] Build: 2016-04-14 15:43:15 by root
I0422 19:33:32.743996 24201 main.cpp:225] Version: 0.28.1
I0422 19:33:32.744005 24201 main.cpp:228] Git tag: 0.28.1
I0422 19:33:32.744014 24201 main.cpp:232] Git SHA: 
555db235a34afbb9fb49940376cc33a66f1f85f0
I0422 19:33:32.746184 24201 systemd.cpp:236] systemd version `219` detected
I0422 19:33:32.746215 24201 main.cpp:240] Inializing systemd state
Failed to initialize systemd: Failed to locate systemd runtime directory: 
/run/systemd/system
root@stavrospc:/# ls /usr/lib/libm*
/usr/lib/libmesos-0.28.1.so  /usr/lib/libmesos.la  /usr/lib/libmesos.so

Any ideas?



> Cannot start mesos local on a Debian GNU/Linux 8 docker machine
> ---
>
> Key: MESOS-3793
> URL: https://issues.apache.org/jira/browse/MESOS-3793
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.25.0
> Environment: Debian GNU/Linux 8 docker machine
>Reporter: Matthias Veit
>Assignee: Jojy Varghese
>  Labels: mesosphere
> Fix For: 0.26.0
>
>
> We updated the mesos version to 0.25.0 in our Marathon docker image, that 
> runs our integration tests.
> We use mesos local for those tests. This fails with this message:
> {noformat}
> root@a06e4b4eb776:/marathon# mesos local
> I1022 18:42:26.852485   136 leveldb.cpp:176] Opened db in 6.103258ms
> I1022 18:42:26.853302   136 leveldb.cpp:183] Compacted db in 765740ns
> I1022 18:42:26.853343   136 leveldb.cpp:198] Created db iterator in 9001ns
> I1022 18:42:26.853355   136 leveldb.cpp:204] Seeked to beginning of db in 
> 1287ns
> I1022 18:42:26.853366   136 leveldb.cpp:273] Iterated through 0 keys in the 
> db in ns
> I1022 18:42:26.853406   136 replica.cpp:744] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1022 18:42:26.853775   141 recover.cpp:449] Starting replica recovery
> I1022 18:42:26.853862   141 recover.cpp:475] Replica is in EMPTY status
> 

[jira] [Commented] (MESOS-3793) Cannot start mesos local on a Debian GNU/Linux 8 docker machine

[Stavros Kontopoulos (JIRA)]

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

Stavros Kontopoulos commented on MESOS-3793:


Still see the issue with mesos 0.28.1 using this images 
https://hub.docker.com/r/osrg/dind-ubuntu-vivid/
and installing mesos as follows:
RUN apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF && \
  DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]') && \
CODENAME=$(lsb_release -cs) && \
echo $CODENAME && \
echo $DISTRO && \
echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | tee 
/etc/apt/sources.list.d/mesosphere.list && \
apt-get -y update && \
VERSION=$(apt-cache madison mesos | head -1 | awk '{ print $3 }')  && \
MARATHON_VERSION=$(apt-cache madison marathon | head -1 | awk '{ print $3 
}') && \
apt-get -y install mesos=$VERSION && \
apt-get install marathon=$MARATHON_VERSION && \
rm -rf /var/lib/apt/lists/*

When i run:
root@stavrospc:/# /usr/sbin/mesos-slave --master=172.17.0.1:5050 
--ip=172.17.0.1 --launcher=posix
I0422 19:33:32.743777 24201 logging.cpp:188] INFO level logging started!
I0422 19:33:32.743979 24201 main.cpp:223] Build: 2016-04-14 15:43:15 by root
I0422 19:33:32.743996 24201 main.cpp:225] Version: 0.28.1
I0422 19:33:32.744005 24201 main.cpp:228] Git tag: 0.28.1
I0422 19:33:32.744014 24201 main.cpp:232] Git SHA: 
555db235a34afbb9fb49940376cc33a66f1f85f0
I0422 19:33:32.746184 24201 systemd.cpp:236] systemd version `219` detected
I0422 19:33:32.746215 24201 main.cpp:240] Inializing systemd state
Failed to initialize systemd: Failed to locate systemd runtime directory: 
/run/systemd/system
root@stavrospc:/# ls /usr/lib/libm*
/usr/lib/libmesos-0.28.1.so  /usr/lib/libmesos.la  /usr/lib/libmesos.so

Any ideas?



> Cannot start mesos local on a Debian GNU/Linux 8 docker machine
> ---
>
> Key: MESOS-3793
> URL: https://issues.apache.org/jira/browse/MESOS-3793
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.25.0
> Environment: Debian GNU/Linux 8 docker machine
>Reporter: Matthias Veit
>Assignee: Jojy Varghese
>  Labels: mesosphere
> Fix For: 0.26.0
>
>
> We updated the mesos version to 0.25.0 in our Marathon docker image, that 
> runs our integration tests.
> We use mesos local for those tests. This fails with this message:
> {noformat}
> root@a06e4b4eb776:/marathon# mesos local
> I1022 18:42:26.852485   136 leveldb.cpp:176] Opened db in 6.103258ms
> I1022 18:42:26.853302   136 leveldb.cpp:183] Compacted db in 765740ns
> I1022 18:42:26.853343   136 leveldb.cpp:198] Created db iterator in 9001ns
> I1022 18:42:26.853355   136 leveldb.cpp:204] Seeked to beginning of db in 
> 1287ns
> I1022 18:42:26.853366   136 leveldb.cpp:273] Iterated through 0 keys in the 
> db in ns
> I1022 18:42:26.853406   136 replica.cpp:744] Replica recovered with log 
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1022 18:42:26.853775   141 recover.cpp:449] Starting replica recovery
> I1022 18:42:26.853862   141 recover.cpp:475] Replica is in EMPTY status
> I1022 18:42:26.854751   138 replica.cpp:641] Replica in EMPTY status received 
> a broadcasted recover request
> I1022 18:42:26.854856   140 recover.cpp:195] Received a recover response from 
> a replica in EMPTY status
> I1022 18:42:26.855002   140 recover.cpp:566] Updating replica status to 
> STARTING
> I1022 18:42:26.855655   138 master.cpp:376] Master 
> a3f39818-1bda-4710-b96b-2a60ed4d12b8 (a06e4b4eb776) started on 
> 172.17.0.14:5050
> I1022 18:42:26.855680   138 master.cpp:378] Flags at startup: 
> --allocation_interval="1secs" --allocator="HierarchicalDRF" 
> --authenticate="false" --authenticate_slaves="false" 
> --authenticators="crammd5" --authorizers="local" --framework_sorter="drf" 
> --help="false" --hostname_lookup="true" --initialize_driver_logging="true" 
> --log_auto_initialize="true" --logbufsecs="0" --logging_level="INFO" 
> --max_slave_ping_timeouts="5" --quiet="false" 
> --recovery_slave_removal_limit="100%" --registry="replicated_log" 
> --registry_fetch_timeout="1mins" --registry_store_timeout="5secs" 
> --registry_strict="false" --root_submissions="true" 
> --slave_ping_timeout="15secs" --slave_reregister_timeout="10mins" 
> --user_sorter="drf" --version="false" --webui_dir="/usr/share/mesos/webui" 
> --work_dir="/tmp/mesos/local/AK0XpG" --zk_session_timeout="10secs"
> I1022 18:42:26.855790   138 master.cpp:425] Master allowing unauthenticated 
> frameworks to register
> I1022 18:42:26.855803   138 master.cpp:430] Master allowing unauthenticated 
> slaves to register
> I1022 18:42:26.855815   138 master.cpp:467] Using default 'crammd5' 
> authenticator
> W1022 18:42:26.855829   138 authenticator.cpp:505] No credentials provided, 
> 

[jira] [Created] (MESOS-5254) Add URI parsing function/library

[Joseph Wu (JIRA)]

Joseph Wu created MESOS-5254:


 Summary: Add URI parsing function/library
 Key: MESOS-5254
 URL: https://issues.apache.org/jira/browse/MESOS-5254
 Project: Mesos
  Issue Type: Task
  Components: fetcher, libprocess
Reporter: Joseph Wu
Assignee: Joseph Wu


The {{uri::Fetcher}} theoretically supports all URIs, per 
[RFC3986|http://tools.ietf.org/html/rfc3986].  To do this, we need a 
spec-compliant parser from string to URI.

[uriparser|http://uriparser.sourceforge.net/] appears to fit the bill.



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

[jira] [Assigned] (MESOS-4558) Reduce the running time of benchmark tests.

[Klaus Ma (JIRA)]

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

Klaus Ma reassigned MESOS-4558:
---

Assignee: Klaus Ma

> Reduce the running time of benchmark tests.
> ---
>
> Key: MESOS-4558
> URL: https://issues.apache.org/jira/browse/MESOS-4558
> Project: Mesos
>  Issue Type: Task
>Reporter: Vinod Kone
>Assignee: Klaus Ma
>  Labels: newbie++
>
> Currently benchmark tests take a long time (>5 hours). It would be nice to 
> reduce the total time taken by the benchmark tests to enable us to run them 
> on ASF CI.
> Command to run only benchmark tests
> {code}
> MESOS_BENCHMARK=1 GTEST_FILTER="*BENCHMARK*" make check
> {code}



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

[jira] [Created] (MESOS-5253) Isolator cleanup should not be invoked if they are not prepared yet.

[Gilbert Song (JIRA)]

Gilbert Song created MESOS-5253:
---

 Summary: Isolator cleanup should not be invoked if they are not 
prepared yet.
 Key: MESOS-5253
 URL: https://issues.apache.org/jira/browse/MESOS-5253
 Project: Mesos
  Issue Type: Bug
  Components: containerization
Affects Versions: 0.28.1, 0.28.0
Reporter: Gilbert Song
Assignee: Gilbert Song
 Fix For: 0.29.0


If the mesos containerizer destroys a container in PROVISIONING state, isolator 
cleanup is still called, which is incorrect because there is no isolator 
prepared yet. 

In this case, there no need to clean up any isolator, call provisioner destroy 
directly.



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

[jira] [Commented] (MESOS-5238) CHECK failure in AppcProvisionerIntegrationTest.ROOT_SimpleLinuxImageTest

[Gilbert Song (JIRA)]

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

Gilbert Song commented on MESOS-5238:
-

This bug is because of a race in mesos containerizer. From the agent log, there 
are two containerizer destroy invoked, which should not be allow. It happened 
because the first time we call the containerizer::destroy, the container state 
is changed from PROVISIONING to DESTROYING, which is fine. But in destroy, the 
containerizer has to wait for all provisioner to finish. If the await() is 
waiting the the second provision(), once the provision() finishes, it invokes 
prepare, which change the container state back to PREPARING. That is incorrect.

So the race comes from we do not check whether the container is being destroyed 
when container is being prepared by isolators.

> CHECK failure in AppcProvisionerIntegrationTest.ROOT_SimpleLinuxImageTest
> -
>
> Key: MESOS-5238
> URL: https://issues.apache.org/jira/browse/MESOS-5238
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.28.0, 0.28.1
> Environment: CentOS 7 + SSL, x86-64
>Reporter: Neil Conway
>Assignee: Gilbert Song
>  Labels: flaky, mesosphere
> Fix For: 0.29.0
>
> Attachments: 5238_check_failure.txt
>
>
> Observed on the Mesosphere internal CI:
> {noformat}
> [22:56:28]W: [Step 10/10] F0420 22:56:28.056788   629 
> containerizer.cpp:1634] Check failed: containers_.contains(containerId)
> {noformat}
> Complete test log will be attached as a file.



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

[jira] [Assigned] (MESOS-5238) CHECK failure in AppcProvisionerIntegrationTest.ROOT_SimpleLinuxImageTest

[Gilbert Song (JIRA)]

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

Gilbert Song reassigned MESOS-5238:
---

Assignee: Gilbert Song

> CHECK failure in AppcProvisionerIntegrationTest.ROOT_SimpleLinuxImageTest
> -
>
> Key: MESOS-5238
> URL: https://issues.apache.org/jira/browse/MESOS-5238
> Project: Mesos
>  Issue Type: Bug
>Affects Versions: 0.28.0, 0.28.1
> Environment: CentOS 7 + SSL, x86-64
>Reporter: Neil Conway
>Assignee: Gilbert Song
>  Labels: flaky, mesosphere
> Fix For: 0.29.0
>
> Attachments: 5238_check_failure.txt
>
>
> Observed on the Mesosphere internal CI:
> {noformat}
> [22:56:28]W: [Step 10/10] F0420 22:56:28.056788   629 
> containerizer.cpp:1634] Check failed: containers_.contains(containerId)
> {noformat}
> Complete test log will be attached as a file.



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

[jira] [Commented] (MESOS-5193) Recovery failed: Failed to recover registrar on reboot of mesos master

[Jie Yu (JIRA)]

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

Jie Yu commented on MESOS-5193:
---

Can you change the work_dir to be /var/lib/mesos and see if the issue gets 
resolved?

The problem with a /tmp workdir is that the replicated log will be wiped upon 
reboot. It'll try to do catch-up with other normal replicas. But if you don't 
have a quorum of normal replicas, the recovery will fail.

> Recovery failed: Failed to recover registrar on reboot of mesos master
> --
>
> Key: MESOS-5193
> URL: https://issues.apache.org/jira/browse/MESOS-5193
> Project: Mesos
>  Issue Type: Bug
>  Components: master
>Affects Versions: 0.22.0, 0.27.0
>Reporter: Priyanka Gupta
>  Labels: master, mesosphere
> Attachments: node1.log, node2.log, node3.log
>
>
> Hi all, 
> We are using a 3 node cluster with mesos master, mesos slave and zookeeper on 
> all of them. We are using chronos on top of it. The problem is when we reboot 
> the mesos master leader, the other nodes try to get elected as leader but 
> fail with recovery registrar issue. 
> "Recovery failed: Failed to recover registrar: Failed to perform fetch within 
> 1mins"
> The next node then try to become the leader but again fails with same error. 
> I am not sure about the issue. We are currently using mesos 0.22 and also 
> tried to upgrade to mesos 0.27 as well but the problem continues to happen. 
>  /usr/sbin/mesos-master --work_dir=/tmp/mesos_dir 
> --zk=zk://node1:2181,node2:2181,node3:2181/mesos --quorum=2
> Can you please help us resolve this issue as its a production system.
> Thanks,
> Priyanka



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

[jira] [Commented] (MESOS-4891) Add a '/containers' endpoint to the agent to list all the active containers.

[Jie Yu (JIRA)]

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

Jie Yu commented on MESOS-4891:
---

commit 8ca09f5f9ca0894d9da8a04e6e6447abca2d3248
Author: Jay Guo 
Date:   Fri Apr 22 09:24:51 2016 -0700

Update docs to reflect /containers endpoint.

Docs are updated using support/generate-endpoint-help.py.

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

> Add a '/containers' endpoint to the agent to list all the active containers.
> 
>
> Key: MESOS-4891
> URL: https://issues.apache.org/jira/browse/MESOS-4891
> Project: Mesos
>  Issue Type: Improvement
>  Components: slave
>Reporter: Jie Yu
>Assignee: Jay Guo
>  Labels: mesosphere
> Fix For: 0.29.0
>
> Attachments: screenshot.png
>
>
> This endpoint will be similar to /monitor/statistics.json endpoint, but it'll 
> also contain the 'container_status' about the container (see ContainerStatus 
> in mesos.proto). We'll eventually deprecate the /monitor/statistics.json 
> endpoint.



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

[jira] [Commented] (MESOS-5227) Implement HTTP Docker Executor that uses the Executor Library

[Yong Tang (JIRA)]

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

Yong Tang commented on MESOS-5227:
--

Thanks [~alexr]! That will be much appreciated. I will add to the reviewer list 
when I submit the review request. Thanks.

> Implement HTTP Docker Executor that uses the Executor Library
> -
>
> Key: MESOS-5227
> URL: https://issues.apache.org/jira/browse/MESOS-5227
> Project: Mesos
>  Issue Type: Bug
>Reporter: Vinod Kone
>Assignee: Yong Tang
>
> Similar to what we did with the HTTP command executor in MESOS-3558 we should 
> have a HTTP docker executor that can speak the v1 Executor API.



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

[jira] [Commented] (MESOS-5227) Implement HTTP Docker Executor that uses the Executor Library

[Alexander Rukletsov (JIRA)]

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

Alexander Rukletsov commented on MESOS-5227:


[~qianzhang], do you want to help review this effort?

> Implement HTTP Docker Executor that uses the Executor Library
> -
>
> Key: MESOS-5227
> URL: https://issues.apache.org/jira/browse/MESOS-5227
> Project: Mesos
>  Issue Type: Bug
>Reporter: Vinod Kone
>Assignee: Yong Tang
>
> Similar to what we did with the HTTP command executor in MESOS-3558 we should 
> have a HTTP docker executor that can speak the v1 Executor API.



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

[jira] [Commented] (MESOS-5227) Implement HTTP Docker Executor that uses the Executor Library

[Yong Tang (JIRA)]

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

Yong Tang commented on MESOS-5227:
--

Hi [~alexr] I just started a couple of days ago. Still looking into how 
MESOS-3558 handles HTTP executor at the moment.

> Implement HTTP Docker Executor that uses the Executor Library
> -
>
> Key: MESOS-5227
> URL: https://issues.apache.org/jira/browse/MESOS-5227
> Project: Mesos
>  Issue Type: Bug
>Reporter: Vinod Kone
>Assignee: Yong Tang
>
> Similar to what we did with the HTTP command executor in MESOS-3558 we should 
> have a HTTP docker executor that can speak the v1 Executor API.



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

[jira] [Commented] (MESOS-5244) Compilation failure on Ubuntu 16.04

[haosdent (JIRA)]

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

haosdent commented on MESOS-5244:
-

I think may be distribute version too old.

> Compilation failure on Ubuntu 16.04
> ---
>
> Key: MESOS-5244
> URL: https://issues.apache.org/jira/browse/MESOS-5244
> Project: Mesos
>  Issue Type: Bug
>  Components: python api
>Reporter: Kapil Arya
>Assignee: Chen Zhiwei
>Priority: Blocker
>  Labels: mesosphere
> Fix For: 0.29.0
>
>
> I saw the following error when trying to compile Mesos on Ubuntu 16.04:
> {code}
> dekaksi:...mesos/build/src> make 
> ../3rdparty/protobuf-2.6.1/python/dist/protobuf-2.6.1-py2.7.egg
> Building protobuf Python egg ...
> cd ../3rdparty/protobuf-2.6.1/python && \
>   CC="gcc"  \
>   CXX="g++" \
>   CFLAGS="-g -O2 -Wno-unused-local-typedefs -g1 -O0"  
>   \
>   CXXFLAGS="-g -O2 -Wno-unused-local-typedefs -Wno-maybe-uninitialized 
> -std=c++11 -g1 -O0"   \
>   PYTHONPATH=/home/kapil/mesos/build/3rdparty/distribute-0.6.26 \
>   /usr/bin/python setup.py build bdist_egg
> Traceback (most recent call last):
>   File "setup.py", line 11, in 
> from setuptools import setup, Extension
>   File 
> "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/setuptools/__init__.py", 
> line 2, in 
> from setuptools.extension import Extension, Library
>   File 
> "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/setuptools/extension.py", 
> line 5, in 
> from setuptools.dist import _get_unpatched
>   File 
> "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/setuptools/dist.py", line 
> 6, in 
> from setuptools.command.install import install
>   File 
> "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/setuptools/command/__init__.py",
>  line 8, in 
> from setuptools.command import install_scripts
>   File 
> "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/setuptools/command/install_scripts.py",
>  line 3, in 
> from pkg_resources import Distribution, PathMetadata, ensure_directory
>   File "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/pkg_resources.py", 
> line 2731, in 
> add_activation_listener(lambda dist: dist.activate())
>   File "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/pkg_resources.py", 
> line 704, in subscribe
> callback(dist)
>   File "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/pkg_resources.py", 
> line 2731, in 
> add_activation_listener(lambda dist: dist.activate())
>   File "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/pkg_resources.py", 
> line 2231, in activate
> self.insert_on(path)
>   File "/home/kapil/mesos/build/3rdparty/distribute-0.6.26/pkg_resources.py", 
> line 2332, in insert_on
> "with distribute. Found one at %s" % str(self.location))
> ValueError: A 0.7-series setuptools cannot be installed with distribute. 
> Found one at /usr/lib/python2.7/dist-packages
> Makefile:10869: recipe for target 
> '../3rdparty/protobuf-2.6.1/python/dist/protobuf-2.6.1-py2.7.egg' failed
> make: *** [../3rdparty/protobuf-2.6.1/python/dist/protobuf-2.6.1-py2.7.egg] 
> Error 1
> {code}



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

[jira] [Commented] (MESOS-5227) Implement HTTP Docker Executor that uses the Executor Library

[Alexander Rukletsov (JIRA)]

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

Alexander Rukletsov commented on MESOS-5227:


Hey [~yongtang], are you working on this issue?

> Implement HTTP Docker Executor that uses the Executor Library
> -
>
> Key: MESOS-5227
> URL: https://issues.apache.org/jira/browse/MESOS-5227
> Project: Mesos
>  Issue Type: Bug
>Reporter: Vinod Kone
>Assignee: Yong Tang
>
> Similar to what we did with the HTTP command executor in MESOS-3558 we should 
> have a HTTP docker executor that can speak the v1 Executor API.



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

[jira] [Created] (MESOS-5252) Introduce state enum in command and docker executors.

[Alexander Rukletsov (JIRA)]

Alexander Rukletsov created MESOS-5252:
--

 Summary: Introduce state enum in command and docker executors.
 Key: MESOS-5252
 URL: https://issues.apache.org/jira/browse/MESOS-5252
 Project: Mesos
  Issue Type: Improvement
Reporter: Alexander Rukletsov


Now after we introduced the fourth state into command executor (MESOS-4908), we 
should consider a introducing state enum and document transitions. This will 
help both readability and quality (i.e. avoiding implementation errors).



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

[jira] [Commented] (MESOS-1104) Move linux/fs.hpp out of `mesos` namespace in linux/fs.h

[Deshi Xiao (JIRA)]

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

Deshi Xiao commented on MESOS-1104:
---

sure. i think this is another purpose to handle not this issue's concerns. 
Maybe the Shepherd can guide it. let it go.

> Move linux/fs.hpp out of `mesos` namespace in linux/fs.h
> 
>
> Key: MESOS-1104
> URL: https://issues.apache.org/jira/browse/MESOS-1104
> Project: Mesos
>  Issue Type: Improvement
>Reporter: Archana kumari
>Assignee: Deshi Xiao
>  Labels: mesosphere, newbie
>




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

[jira] [Assigned] (MESOS-4988) Excluded reserved resources when got nonRevocable resources in stage 1.

[Klaus Ma (JIRA)]

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

Klaus Ma reassigned MESOS-4988:
---

Assignee: Klaus Ma

> Excluded reserved resources when got nonRevocable resources in stage 1.
> ---
>
> Key: MESOS-4988
> URL: https://issues.apache.org/jira/browse/MESOS-4988
> Project: Mesos
>  Issue Type: Bug
>  Components: allocation
>Reporter: Klaus Ma
>Assignee: Klaus Ma
>
> Allocator will only allocate non-revocable resources to satify quota. As the 
> reserved resources can not be revocable, it's not necessary to call 
> `nonRevocable()` for reserved resources.



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

[jira] [Updated] (MESOS-4988) Excluded reserved resources when got nonRevocable resources in stage 1.

[Klaus Ma (JIRA)]

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

Klaus Ma updated MESOS-4988:

Assignee: (was: Klaus Ma)

> Excluded reserved resources when got nonRevocable resources in stage 1.
> ---
>
> Key: MESOS-4988
> URL: https://issues.apache.org/jira/browse/MESOS-4988
> Project: Mesos
>  Issue Type: Bug
>  Components: allocation
>Reporter: Klaus Ma
>
> Allocator will only allocate non-revocable resources to satify quota. As the 
> reserved resources can not be revocable, it's not necessary to call 
> `nonRevocable()` for reserved resources.



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