[jira] [Assigned] (MESOS-5613) mesos-local fails to start if MESOS_WORK_DIR isn't set.
[
https://issues.apache.org/jira/browse/MESOS-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Dasgupta reassigned MESOS-5613:
Assignee: Abhishek Dasgupta
> mesos-local fails to start if MESOS_WORK_DIR isn't set.
> ---
>
> Key: MESOS-5613
> URL: https://issues.apache.org/jira/browse/MESOS-5613
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Jan Schlicht
>Assignee: Abhishek Dasgupta
>
> Running {{mesos-local}} fails with
> {noformat}
> Failed to start a local cluster while loading agent flags from the
> environment: Flag 'work_dir' is required, but it was not provided
> {noformat}
> if {{MESOS_WORK_DIR}} isn't set.
> This seems to be due to the changed behavior of making the {{work_dir}} flag
> mandatory (MESOS-5064). While {{MESOS_WORK_DIR}} is being set in a
> development environment in {{./bin/mesos-local.sh}}, this isn't true if
> {{mesos-local}} is installed on the system after a {{make install}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5487) Implement LIST_FILES Call in v1 master API.
[ https://issues.apache.org/jira/browse/MESOS-5487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent updated MESOS-5487: Assignee: Abhishek Dasgupta (was: haosdent) > Implement LIST_FILES Call in v1 master API. > --- > > Key: MESOS-5487 > URL: https://issues.apache.org/jira/browse/MESOS-5487 > Project: Mesos > Issue Type: Task >Reporter: Vinod Kone >Assignee: Abhishek Dasgupta > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4791) Operator API v1
[ https://issues.apache.org/jira/browse/MESOS-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15330831#comment-15330831 ] Vinod Kone commented on MESOS-4791: --- [~a10gupta], [~haosd...@gmail.com] and [~guoger] please make sure to transition the tickets to "Reviewable" if you have reviews out for them. Also, don't forget to add comments to the proto files describing the calls, parameters and responses. > Operator API v1 > --- > > Key: MESOS-4791 > URL: https://issues.apache.org/jira/browse/MESOS-4791 > Project: Mesos > Issue Type: Epic >Reporter: Vinod Kone > > This epic captures the work needed to update the current master HTTP > endpoints for operators (e.g., /state, /metrics/snapshot). > Some problems with the current operator endpoints > --> No versioning > --> Access patterns are not consistent (DELETE on /quota vs /destroy-volume) > --> No published/standard schemas for requests or responses > Note that we are doing similar work for Framework API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5582) Create a `cgroups/devices` isolator.
[
https://issues.apache.org/jira/browse/MESOS-5582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15330504#comment-15330504
]
Benjamin Mahler commented on MESOS-5582:
Fix for a double cgroups::destoy issue that was introduced:
{noformat}
commit e29ce100873f0901a6f4af13db5b25d5524b613f
Author: Kevin Klues
Date: Tue Jun 14 13:11:08 2016 -0700
Fixed bug with double destruction of cgroups devices subsystem.
In a previous commit, the `cgroups/devices` isolator was abstracted
out of the Nvidia GPU isolator. However, the code for destroying the
devices susbsystem wasn't removed from the GPU isolator, causing it to
"double destroy" the subsystem upon cleanup. This commit removed this
redundant code.
Review: https://reviews.apache.org/r/48578/
{noformat}
> Create a `cgroups/devices` isolator.
>
>
> Key: MESOS-5582
> URL: https://issues.apache.org/jira/browse/MESOS-5582
> Project: Mesos
> Issue Type: Improvement
>Reporter: Kevin Klues
>Assignee: Kevin Klues
> Labels: gpu, isolator, mesosphere
>
> Currently, all the logic for the `cgroups/devices` isolator is bundled into
> the Nvidia GPU Isolator. We should abstract it out into it's own component
> and remove the redundant logic from the Nvidia GPU Isolator. Assuming the
> guaranteed ordering between isolators from MESOS-5581, we can be sure that
> the dependency order between the `cgroups/devices` and `gpu/nvidia` isolators
> is met.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5514) Implement LIST_FILES Call in v1 agent API.
[ https://issues.apache.org/jira/browse/MESOS-5514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15330224#comment-15330224 ] Abhishek Dasgupta commented on MESOS-5514: -- RR : https://reviews.apache.org/r/48704/ https://reviews.apache.org/r/48705/ > Implement LIST_FILES Call in v1 agent API. > -- > > Key: MESOS-5514 > URL: https://issues.apache.org/jira/browse/MESOS-5514 > Project: Mesos > Issue Type: Task >Reporter: Vinod Kone >Assignee: Abhishek Dasgupta > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5583) Improve authorization documentation when setting permissive flag.
[ https://issues.apache.org/jira/browse/MESOS-5583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schad updated MESOS-5583: --- Shepherd: Till Toenshoff (was: Adam B) > Improve authorization documentation when setting permissive flag. > - > > Key: MESOS-5583 > URL: https://issues.apache.org/jira/browse/MESOS-5583 > Project: Mesos > Issue Type: Documentation >Reporter: Joerg Schad >Assignee: Joerg Schad > > A common problem for a users starting to use acls is that once they set > `permisse = false` and not add acls allowing common operations (e.g., > register_framework) their Mesos cluster don't > behave as expected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5613) mesos-local fails to start if MESOS_WORK_DIR isn't set.
[
https://issues.apache.org/jira/browse/MESOS-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Schlicht updated MESOS-5613:
Summary: mesos-local fails to start if MESOS_WORK_DIR isn't set. (was:
mesos-local fails to start if work dir is set using flags)
> mesos-local fails to start if MESOS_WORK_DIR isn't set.
> ---
>
> Key: MESOS-5613
> URL: https://issues.apache.org/jira/browse/MESOS-5613
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Jan Schlicht
>Priority: Minor
>
> Running {{mesos-local --work_dir=/var/run/mesos}} fails with
> {noformat}
> Failed to start a local cluster while loading agent flags from the
> environment: Flag 'work_dir' is required, but it was not provided
> {noformat}
> Running {{MESOS_WORK_DIR=/var/run/mesos mesos-local}} works fine, though.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5613) mesos-local fails to start if MESOS_WORK_DIR isn't set.
[
https://issues.apache.org/jira/browse/MESOS-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Schlicht updated MESOS-5613:
Description:
Running {{mesos-local}} fails with
{noformat}
Failed to start a local cluster while loading agent flags from the environment:
Flag 'work_dir' is required, but it was not provided
{noformat}
if {{MESOS_WORK_DIR}} isn't set.
This seems to be due to the changed behavior of making the {{work_dir}} flag
mandatory (MESOS-5064). While {{MESOS_WORK_DIR}} is being set in a development
environment in {{./bin/mesos-local.sh}}, this isn't true if {{mesos-local}} is
installed on the system after a {{make install}}.
was:
Running {{mesos-local}} fails with
{noformat}
Failed to start a local cluster while loading agent flags from the environment:
Flag 'work_dir' is required, but it was not provided
{noformat}
if {{MESOS_WORK_DIR}} isn't set.
> mesos-local fails to start if MESOS_WORK_DIR isn't set.
> ---
>
> Key: MESOS-5613
> URL: https://issues.apache.org/jira/browse/MESOS-5613
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Jan Schlicht
>Priority: Minor
>
> Running {{mesos-local}} fails with
> {noformat}
> Failed to start a local cluster while loading agent flags from the
> environment: Flag 'work_dir' is required, but it was not provided
> {noformat}
> if {{MESOS_WORK_DIR}} isn't set.
> This seems to be due to the changed behavior of making the {{work_dir}} flag
> mandatory (MESOS-5064). While {{MESOS_WORK_DIR}} is being set in a
> development environment in {{./bin/mesos-local.sh}}, this isn't true if
> {{mesos-local}} is installed on the system after a {{make install}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5613) mesos-local fails to start if MESOS_WORK_DIR isn't set.
[
https://issues.apache.org/jira/browse/MESOS-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Schlicht updated MESOS-5613:
Priority: Major (was: Minor)
> mesos-local fails to start if MESOS_WORK_DIR isn't set.
> ---
>
> Key: MESOS-5613
> URL: https://issues.apache.org/jira/browse/MESOS-5613
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Jan Schlicht
>
> Running {{mesos-local}} fails with
> {noformat}
> Failed to start a local cluster while loading agent flags from the
> environment: Flag 'work_dir' is required, but it was not provided
> {noformat}
> if {{MESOS_WORK_DIR}} isn't set.
> This seems to be due to the changed behavior of making the {{work_dir}} flag
> mandatory (MESOS-5064). While {{MESOS_WORK_DIR}} is being set in a
> development environment in {{./bin/mesos-local.sh}}, this isn't true if
> {{mesos-local}} is installed on the system after a {{make install}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5611) Error message is not clear when create docker volume with absolute path
Guangya Liu created MESOS-5611:
--
Summary: Error message is not clear when create docker volume with
absolute path
Key: MESOS-5611
URL: https://issues.apache.org/jira/browse/MESOS-5611
Project: Mesos
Issue Type: Bug
Components: isolation
Reporter: Guangya Liu
Assignee: Guangya Liu
When I was doing some test with mesos-execute to mount some volumes, I found
that the error message is not clear when I was using absolute path for a
container without rootfs.
{code}
root@mesos002:~/src/mesos/m2/mesos/build# ./src/mesos-execute
--master=192.168.56.12:5050 --command="sleep 10" --name=test
--volumes=/root/test/volume4.json
WARNING: Logging before InitGoogleLogging() is written to STDERR
W0614 09:21:25.100939 28209 parse.hpp:115] Specifying an absolute filename to
read a command line option out of without using 'file:// is deprecated and will
be removed in a future release. Simply adding 'file://' to the beginning of the
path should eliminate this warning.
I0614 09:21:25.104532 28209 scheduler.cpp:187] Version: 1.0.0
I0614 09:21:25.106834 28231 scheduler.cpp:471] New master detected at
master@192.168.56.12:5050
Subscribed with ID '57cda92a-b703-435a-94f0-28e88746f8b5-'
Submitted task 'test' to agent '57cda92a-b703-435a-94f0-28e88746f8b5-S0'
Received status update TASK_FAILED for task 'test'
message: 'Failed to launch container: Absolute container path does not exist;
Container destroyed while preparing isolators'
{code}
The error message {{Absolute container path does not exist;}} should include
the absolute path.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5608) Apache Pre-Compiled Tarballs
[ https://issues.apache.org/jira/browse/MESOS-5608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15329106#comment-15329106 ] Hari Sekhon commented on MESOS-5608: I'm aware they're build/packaging number suffixes, and while there is clearly a pattern it's not really predictable in a suitable way for automated builds - I did actually use that page to find the exact filenames and hard code them... but that doesn't seem the right way of doing things. I've tried the apt repo as well, but it doesn't seem to take prior version numbers to install, eg. mesos- where version might be 0.23 or 0.23.0 doesn't seem to work (I build multiple versions for backwards compatibility testing) and is non-browseable so I can't see what's available, for example http://repos.mesosphere.io/debian gives "The specified key does not exist". > Apache Pre-Compiled Tarballs > > > Key: MESOS-5608 > URL: https://issues.apache.org/jira/browse/MESOS-5608 > Project: Mesos > Issue Type: Task >Reporter: Hari Sekhon >Priority: Minor > > Request for pre-compiled tarballs on the apache download mirrors and > apache.archive.org for older versions. > I used to compile this myself but nowadays I use Docker builds a lot and > don't want to be forced to have lots of dev build tooling bloating my docker > images to build this from source. > Most other apache projects provide both the source tarball as well as > precompiled tarball. > I've used Mesosphere's downloads as they provide rpms + debs but the problem > is their URLs have non-deterministric build suffixes appended to each version > so that I cannot build or update across versions without hardcoding the > almost random build suffixes for every minor version change as I can't > predict the build suffixes. > Normal apache tarballs with consistent names seems like something common to > Apache projects that the Mesos project is currently missing. > Thanks > Hari -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-5447) Configurable agent memory reservation
[ https://issues.apache.org/jira/browse/MESOS-5447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Dasgupta reassigned MESOS-5447: Assignee: Abhishek Dasgupta > Configurable agent memory reservation > - > > Key: MESOS-5447 > URL: https://issues.apache.org/jira/browse/MESOS-5447 > Project: Mesos > Issue Type: Improvement >Reporter: Karl Isenberg >Assignee: Abhishek Dasgupta > > When deciding what memory to make available to tasks (if not explicitly > configured), mesos agents currently reserve 1GB or 1/2 of system memory. > I'd really like to be able to configure the reservation amount so that I > don't have to reproduce the system memory lookup and math in order to > configure "mem=(system memory - reservation)". > Ideally this would be configurable with a command line argument and > environment variable like "--reserved-memory=512". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5610) Transition Docker image "whiteout" deletion from FTS to something Windows-compatible
Alex Clemmer created MESOS-5610: --- Summary: Transition Docker image "whiteout" deletion from FTS to something Windows-compatible Key: MESOS-5610 URL: https://issues.apache.org/jira/browse/MESOS-5610 Project: Mesos Issue Type: Bug Components: containerization Reporter: Alex Clemmer Assignee: Alex Clemmer In `slave/containerizer/mesos/provisioner/provisioner.cpp`, the function `ProvisionerProcess::__provision` uses the FTS API to walk the directory and delete some files and directories per the Docker v1 spec[1]. The FTS API conforms to BSD; it is not available on Windows. We therefore have 2 options: we can (1) prove we don't need this for Windows Containers, or (2) implement a version of this code that does not depend on FTS, in a manner similar to our modifications to `os::rmdir`. [1] https://github.com/docker/docker/blob/master/image/spec/v1.md -- This message was sent by Atlassian JIRA (v6.3.4#6332)
