[jira] [Commented] (MESOS-4735) CommandInfo.URI should allow specifying target filename
[
https://issues.apache.org/jira/browse/MESOS-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/MESOS-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/MESOS-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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"
[ https://issues.apache.org/jira/browse/MESOS-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/MESOS-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/MESOS-5254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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 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 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
[ https://issues.apache.org/jira/browse/MESOS-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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.
[ 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
[ https://issues.apache.org/jira/browse/MESOS-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/MESOS-5257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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 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.
[
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
[
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
[
https://issues.apache.org/jira/browse/MESOS-5255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[
https://issues.apache.org/jira/browse/MESOS-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[jira] [Updated] (MESOS-1865) Redirect to the leader master when current master is not a leader
[
https://issues.apache.org/jira/browse/MESOS-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinod Kone updated MESOS-1865:
--
Shepherd: Vinod Kone (was: Adam B)
Sprint: Mesosphere Sprint 33
Story Points: 3
> Redirect to the leader master when current master is not a leader
> -
>
> Key: MESOS-1865
> URL: https://issues.apache.org/jira/browse/MESOS-1865
> Project: Mesos
> Issue Type: Bug
> Components: json api
>Affects Versions: 0.20.1
>Reporter: Steven Schlansker
>Assignee: haosdent
> Fix For: 0.29.0
>
>
> Some of the API endpoints, for example /master/tasks.json, will return bogus
> information if you query a non-leading master:
> {code}
> [steven@Anesthetize:~]% curl
> http://master1.mesos-vpcqa.otenv.com:5050/master/tasks.json | jq . | head -n
> 10
> {
> "tasks": []
> }
> [steven@Anesthetize:~]% curl
> http://master2.mesos-vpcqa.otenv.com:5050/master/tasks.json | jq . | head -n
> 10
> {
> "tasks": []
> }
> [steven@Anesthetize:~]% curl
> http://master3.mesos-vpcqa.otenv.com:5050/master/tasks.json | jq . | head -n
> 10
> {
> "tasks": [
> {
> "executor_id": "",
> "framework_id": "20140724-231003-419644938-5050-1707-",
> "id":
> "pp.guestcenterwebhealthmonitor.606cd6ee-4b50-11e4-825b-5212e05f35db",
> "name":
> "pp.guestcenterwebhealthmonitor.606cd6ee-4b50-11e4-825b-5212e05f35db",
> "resources": {
> "cpus": 0.25,
> "disk": 0,
> {code}
> This is very hard for end-users to work around. For example if I query
> "which master is leading" followed by "leader: which tasks are running" it is
> possible that the leader fails over in between, leaving me with an incorrect
> answer and no way to know that this happened.
> In my opinion the API should return the correct response (by asking the
> current leader?) or an error (500 Not the leader?) but it's unacceptable to
> return a successful wrong answer.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5014) Call and Event Type enums in scheduler.proto should be optional
[ https://issues.apache.org/jira/browse/MESOS-5014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MESOS-5015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ https://issues.apache.org/jira/browse/MESOS-5031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/MESOS-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/MESOS-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
> I102
[jira] [Comment Edited] (MESOS-3793) Cannot start mesos local on a Debian GNU/Linux 8 docker machine
[
https://issues.apache.org/jira/browse/MESOS-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] Compacte
[jira] [Comment Edited] (MESOS-3793) Cannot start mesos local on a Debian GNU/Linux 8 docker machine
[
https://issues.apache.org/jira/browse/MESOS-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.c
[jira] [Comment Edited] (MESOS-3793) Cannot start mesos local on a Debian GNU/Linux 8 docker machine
[
https://issues.apache.org/jira/browse/MESOS-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/MESOS-4543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/MESOS-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 recov
[jira] [Comment Edited] (MESOS-3793) Cannot start mesos local on a Debian GNU/Linux 8 docker machine
[
https://issues.apache.org/jira/browse/MESOS-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 14
[jira] [Comment Edited] (MESOS-3793) Cannot start mesos local on a Debian GNU/Linux 8 docker machine
[
https://issues.apache.org/jira/browse/MESOS-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[jira] [Commented] (MESOS-3793) Cannot start mesos local on a Debian GNU/Linux 8 docker machine
[
https://issues.apache.org/jira/browse/MESOS-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 provide
[jira] [Created] (MESOS-5254) Add URI parsing function/library
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.
[
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] [Updated] (MESOS-5238) CHECK failure in AppcProvisionerIntegrationTest.ROOT_SimpleLinuxImageTest
[
https://issues.apache.org/jira/browse/MESOS-5238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilbert Song updated MESOS-5238:
Shepherd: Jie Yu
Sprint: Mesosphere Sprint 33
Story Points: 2
Labels: containerizer flaky mesosphere (was: flaky mesosphere)
> 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: containerizer, 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] [Created] (MESOS-5253) Isolator cleanup should not be invoked if they are not prepared yet.
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
[
https://issues.apache.org/jira/browse/MESOS-5238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
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
[ https://issues.apache.org/jira/browse/MESOS-5193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ https://issues.apache.org/jira/browse/MESOS-4891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MESOS-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MESOS-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MESOS-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/MESOS-5244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MESOS-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ https://issues.apache.org/jira/browse/MESOS-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[ 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.
[ 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)
