[jira] [Created] (MESOS-5470) Confirm errors in authorized persistent volume tests
Greg Mann created MESOS-5470:
Summary: Confirm errors in authorized persistent volume tests
Key: MESOS-5470
URL: https://issues.apache.org/jira/browse/MESOS-5470
Project: Mesos
Issue Type: Bug
Components: tests
Reporter: Greg Mann
Priority: Minor
The tests {{PersistentVolumeTest.BadACLDropCreateAndDestroy}} and
{{PersistentVolumeTest.BadACLNoPrincipal}} check for a failed Destroy operation
by confirming that the persistent volume is still contained in an offer
received after the attempted operation. We should also explicitly check that
the operation did not succeed due to failed authorization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5468) Add logic in long-lived-framework to handle network partitions.
[
https://issues.apache.org/jira/browse/MESOS-5468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15303537#comment-15303537
]
Anand Mazumdar commented on MESOS-5468:
---
[~guoger] I edited the JIRA description a bit. Let me know if it does not align
with your observations.
Also, we do close the socket on the master's side upon a framework
disconnect/teardown.
https://github.com/apache/mesos/blob/master/src/master/master.cpp#L2795
Can you confirm on your end if you are not seeing this behavior and some steps
to reproduce it?
> Add logic in long-lived-framework to handle network partitions.
> ---
>
> Key: MESOS-5468
> URL: https://issues.apache.org/jira/browse/MESOS-5468
> Project: Mesos
> Issue Type: Task
> Components: framework, master
>Reporter: Jay Guo
>
> Currently long-lived-framework does not handle network partitions i.e
> explicitly trying to {{reconnect}} with the master upon not receiving
> {{HEARTBEAT}} events for a prolonged amount of time. If the master
> disconnects a framework without the framework being aware of it (one way
> partition), the framework should explicitly issue a {{reconnect}} request via
> the scheduler library after a certain period of time.
> *On the other hand*, should we close TCP socket on master side when teardown
> a framework? Currently the tcp socket is left alive even framework has been
> deactivated. This results in framework sending invalid {{Call}} to master and
> re-detection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5468) Add logic in long-lived-framework to handle network partitions.
[
https://issues.apache.org/jira/browse/MESOS-5468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anand Mazumdar updated MESOS-5468:
--
Description:
Currently long-lived-framework does not handle network partitions i.e
explicitly trying to {{reconnect}} with the master upon not receiving
{{HEARTBEAT}} events for a prolonged amount of time. If the master disconnects
a framework without the framework being aware of it (one way partition), the
framework should explicitly issue a {{reconnect}} request via the scheduler
library after a certain period of time.
*On the other hand*, should we close TCP socket on master side when teardown a
framework? Currently the tcp socket is left alive even framework has been
deactivated. This results in framework sending invalid {{Call}} to master and
re-detection.
was:
Currently long-lived-framework does not handle HEARTBEAT timeout. If master
teardown the framework without framework being aware of it (network partition),
the framework keeps waiting for {{Event}} until reconnected.
*On the other hand*, should we close TCP socket on master side when teardown a
framework? Currently the tcp socket is left alive even framework has been
deactivated. This results in framework sending invalid {{Call}} to master and
re-detection.
> Add logic in long-lived-framework to handle network partitions.
> ---
>
> Key: MESOS-5468
> URL: https://issues.apache.org/jira/browse/MESOS-5468
> Project: Mesos
> Issue Type: Task
> Components: framework, master
>Reporter: Jay Guo
>
> Currently long-lived-framework does not handle network partitions i.e
> explicitly trying to {{reconnect}} with the master upon not receiving
> {{HEARTBEAT}} events for a prolonged amount of time. If the master
> disconnects a framework without the framework being aware of it (one way
> partition), the framework should explicitly issue a {{reconnect}} request via
> the scheduler library after a certain period of time.
> *On the other hand*, should we close TCP socket on master side when teardown
> a framework? Currently the tcp socket is left alive even framework has been
> deactivated. This results in framework sending invalid {{Call}} to master and
> re-detection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5468) Add logic in long-lived-framework to handle network partitions.
[
https://issues.apache.org/jira/browse/MESOS-5468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anand Mazumdar updated MESOS-5468:
--
Summary: Add logic in long-lived-framework to handle network partitions.
(was: Add logic to long-lived-framework to handle HEARTBEAT timeout)
> Add logic in long-lived-framework to handle network partitions.
> ---
>
> Key: MESOS-5468
> URL: https://issues.apache.org/jira/browse/MESOS-5468
> Project: Mesos
> Issue Type: Bug
> Components: framework, master
>Reporter: Jay Guo
>
> Currently long-lived-framework does not handle HEARTBEAT timeout. If master
> teardown the framework without framework being aware of it (network
> partition), the framework keeps waiting for {{Event}} until reconnected.
> *On the other hand*, should we close TCP socket on master side when teardown
> a framework? Currently the tcp socket is left alive even framework has been
> deactivated. This results in framework sending invalid {{Call}} to master and
> re-detection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5468) Add logic in long-lived-framework to handle network partitions.
[
https://issues.apache.org/jira/browse/MESOS-5468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anand Mazumdar updated MESOS-5468:
--
Issue Type: Task (was: Bug)
> Add logic in long-lived-framework to handle network partitions.
> ---
>
> Key: MESOS-5468
> URL: https://issues.apache.org/jira/browse/MESOS-5468
> Project: Mesos
> Issue Type: Task
> Components: framework, master
>Reporter: Jay Guo
>
> Currently long-lived-framework does not handle HEARTBEAT timeout. If master
> teardown the framework without framework being aware of it (network
> partition), the framework keeps waiting for {{Event}} until reconnected.
> *On the other hand*, should we close TCP socket on master side when teardown
> a framework? Currently the tcp socket is left alive even framework has been
> deactivated. This results in framework sending invalid {{Call}} to master and
> re-detection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5469) Remove hard-coded principals in `PersistentVolumeEndpointsTest.SlavesEndpointFullResources`
Greg Mann created MESOS-5469:
Summary: Remove hard-coded principals in
`PersistentVolumeEndpointsTest.SlavesEndpointFullResources`
Key: MESOS-5469
URL: https://issues.apache.org/jira/browse/MESOS-5469
Project: Mesos
Issue Type: Task
Components: tests
Reporter: Greg Mann
In the test {{PersistentVolumeEndpointsTest.SlavesEndpointFullResources}}, the
value {{test-principal}} is hard-coded into the JSON strings expected in HTTP
responses. It would be more durable to use {{DEFAULT_CREDENTIAL.principal()}}
instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5468) Add logic to long-lived-framework to handle HEARTBEAT timeout
[
https://issues.apache.org/jira/browse/MESOS-5468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15303509#comment-15303509
]
Jay Guo commented on MESOS-5468:
To reproduce:
* Start master and agent
* Run long-lived-framework
* Issue {{# iptables -A OUTPUT -p tcp -d --dport 5050 -j DROP}} on
framework machine to emulate network partition
* Wait till master deactivates the framework
* Remove iptables rule added above to emulate network rejoin
* See log of both long-lived-framework and master. {{netstat -tpn}} also shows
enormous {{TIME_WAIT}} sockets which is the result of re-detection
> Add logic to long-lived-framework to handle HEARTBEAT timeout
> -
>
> Key: MESOS-5468
> URL: https://issues.apache.org/jira/browse/MESOS-5468
> Project: Mesos
> Issue Type: Bug
> Components: framework, master
>Reporter: Jay Guo
>
> Currently long-lived-framework does not handle HEARTBEAT timeout. If master
> teardown the framework without framework being aware of it (network
> partition), the framework keeps waiting for {{Event}} until reconnected.
> *On the other hand*, should we close TCP socket on master side when teardown
> a framework? Currently the tcp socket is left alive even framework has been
> deactivated. This results in framework sending invalid {{Call}} to master and
> re-detection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5468) Add logic to long-lived-framework to handle HEARTBEAT timeout
Jay Guo created MESOS-5468:
--
Summary: Add logic to long-lived-framework to handle HEARTBEAT
timeout
Key: MESOS-5468
URL: https://issues.apache.org/jira/browse/MESOS-5468
Project: Mesos
Issue Type: Bug
Components: framework, master
Reporter: Jay Guo
Currently long-lived-framework does not handle HEARTBEAT timeout. If master
teardown the framework without framework being aware of it (network partition),
the framework keeps waiting for {{Event}} until reconnected.
*On the other hand*, should we close TCP socket on master side when teardown a
framework? Currently the tcp socket is left alive even framework has been
deactivated. This results in framework sending invalid {{Call}} to master and
re-detection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5467) offer DECLINE / ACCEPT + Recovered resource messages are spammy
Cody Maloney created MESOS-5467:
---
Summary: offer DECLINE / ACCEPT + Recovered resource messages are
spammy
Key: MESOS-5467
URL: https://issues.apache.org/jira/browse/MESOS-5467
Project: Mesos
Issue Type: Bug
Reporter: Cody Maloney
When in a decent size Mesos cluster, frameworks get sent hundreds of offers.
When the framework than accepts/declines those offers,
{noformat}
May 27 01:20:43 node-44a84216f97e mesos-master[110696]: I0527 01:20:43.361552
110718 master.cpp:3297] Processing DECLINE call for offers: [
88bbf084-c8b7-4c91-af62-c91089c97eaf-O433278814 ] for framework
20160406-160033-18415882-5050-35855- (mon-marathon-service) at
scheduler-949644bc-b1f0-497b-a767-87d1201d5113@10.6.15.1:41319
{noformat}
will be printed for each of them. Along with a:
{noformat}
May 27 01:20:43 node-44a84216f97e mesos-master[110696]: I0527 01:20:43.419852
110703 hierarchical.cpp:744] Recovered cpus(*):37.75; mem(*):102992;
ports(*):[31000-31214, 31216-32000]; disk(*):545870 (total: cpus(*):38;
mem(*):103120; ports(*):[31000-32000]; disk(*):545870, allocated: cpus(*):0.25;
mem(*):128; ports(*):[31215-31215]) on slave
88bbf084-c8b7-4c91-af62-c91089c97eaf-S649 from framework
20160406-160033-18415882-5050-35855-
{noformat}
Would be nice to not log the exact declines, or to do a summary. This ends up
being the vast majority of logs I look at (multi-thousand line blocks of logs
which aren't useful to the investigation. Just need a sign "offers are being
processed for this framework").
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5466) Master attempted to send message to disconnected framework logged 800 times in 1 second
[ https://issues.apache.org/jira/browse/MESOS-5466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cody Maloney updated MESOS-5466: Attachment: master-disconnect-message > Master attempted to send message to disconnected framework logged 800 times > in 1 second > --- > > Key: MESOS-5466 > URL: https://issues.apache.org/jira/browse/MESOS-5466 > Project: Mesos > Issue Type: Bug > Components: master >Reporter: Cody Maloney > Labels: mesosphere > Attachments: master-disconnect-message > > > One instance (attached) had 806 of exactly the same message in one second. > Anonymized log attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-5465) Container image as a volume source should also include image manifest.
[ https://issues.apache.org/jira/browse/MESOS-5465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guangya Liu reassigned MESOS-5465: -- Assignee: Guangya Liu > Container image as a volume source should also include image manifest. > -- > > Key: MESOS-5465 > URL: https://issues.apache.org/jira/browse/MESOS-5465 > Project: Mesos > Issue Type: Bug >Reporter: Jie Yu >Assignee: Guangya Liu > > Currently, if a user specifies the source of a volume to be an image (e.g., > Docker image), we only prepare the rootfs and mount it at 'container_path' in > the container. > However, the rootfs itself is not sufficient to allow the executor to launch > the docker container. We need the docker manifest as well to get the env, > entry point, cmd information. > One solutions is to make container_path a directory containing two things: 1) > rootfs, 2) manifest. But this is a breaking change, we might need to > introduce a deprecation cycle for that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5464) The max number of completed executors for a mesos slave should be configurable
[ https://issues.apache.org/jira/browse/MESOS-5464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Johnstone updated MESOS-5464: --- Remaining Estimate: 24h (was: 1h) Original Estimate: 24h (was: 1h) > The max number of completed executors for a mesos slave should be configurable > -- > > Key: MESOS-5464 > URL: https://issues.apache.org/jira/browse/MESOS-5464 > Project: Mesos > Issue Type: Improvement >Reporter: Kevin Johnstone >Priority: Trivial > Original Estimate: 24h > Remaining Estimate: 24h > > The number of completed executors per framework should be configurable. > Frameworks such as Chronos make one executor per tasks and the default of 150 > executors makes sandbox logs inaccessible through the mesos UI very quickly, > far before the specified timeout for garbage collection for a task. > https://github.com/apache/mesos/blob/4db9b630cc67f706a8814436309ab589cbaa64fc/src/slave/constants.hpp#L64 > shows where the constant is currently set. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MESOS-5415) bootstrap of libprocess fails.
[
https://issues.apache.org/jira/browse/MESOS-5415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15303164#comment-15303164
]
Kapil Arya edited comment on MESOS-5415 at 5/26/16 11:34 PM:
-
RRs:
https://reviews.apache.org/r/47924/
https://reviews.apache.org/r/47925/
https://reviews.apache.org/r/47927/
https://reviews.apache.org/r/47928/
https://reviews.apache.org/r/47929/
was (Author: karya):
RRs:
https://reviews.apache.org/r/47924/
https://reviews.apache.org/r/47925/
https://reviews.apache.org/r/47926/
https://reviews.apache.org/r/47927/
> bootstrap of libprocess fails.
> --
>
> Key: MESOS-5415
> URL: https://issues.apache.org/jira/browse/MESOS-5415
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.29.0
>Reporter: Till Toenshoff
>Assignee: Kapil Arya
>
> When trying to build libprocess on its own, I am hitting the following:
> {noformat}
> $ pwd
> /home/till/scratchpad/mesos/3rdparty/libprocess
> $ ./bootstrap
> […]
> configure.ac:64: error: required file '3rdparty/gmock_sources.cc.in' not found
> {noformat}
> So the standalone {{configure.ac}} still tries to locate
> {{gmock_source.cc.in}} in a subfolder called {{3rdparty}} while it should
> actually try to locate it in its parent folder.
> {noformat}
> $ ll /home/till/scratchpad/mesos/3rdparty/gmock_sources.cc.in
> -rw-rw-r--. 1 till till 730 May 19 13:22
> /home/till/scratchpad/mesos/3rdparty/gmock_sources.cc.in
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5415) bootstrap of libprocess fails.
[
https://issues.apache.org/jira/browse/MESOS-5415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kapil Arya updated MESOS-5415:
--
Shepherd: Till Toenshoff
> bootstrap of libprocess fails.
> --
>
> Key: MESOS-5415
> URL: https://issues.apache.org/jira/browse/MESOS-5415
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.29.0
>Reporter: Till Toenshoff
>Assignee: Kapil Arya
>
> When trying to build libprocess on its own, I am hitting the following:
> {noformat}
> $ pwd
> /home/till/scratchpad/mesos/3rdparty/libprocess
> $ ./bootstrap
> […]
> configure.ac:64: error: required file '3rdparty/gmock_sources.cc.in' not found
> {noformat}
> So the standalone {{configure.ac}} still tries to locate
> {{gmock_source.cc.in}} in a subfolder called {{3rdparty}} while it should
> actually try to locate it in its parent folder.
> {noformat}
> $ ll /home/till/scratchpad/mesos/3rdparty/gmock_sources.cc.in
> -rw-rw-r--. 1 till till 730 May 19 13:22
> /home/till/scratchpad/mesos/3rdparty/gmock_sources.cc.in
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-5416) make check of stout fails.
[
https://issues.apache.org/jira/browse/MESOS-5416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kapil Arya reassigned MESOS-5416:
-
Assignee: Kapil Arya (was: haosdent)
> make check of stout fails.
> --
>
> Key: MESOS-5416
> URL: https://issues.apache.org/jira/browse/MESOS-5416
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.29.0
>Reporter: Till Toenshoff
>Assignee: Kapil Arya
>
> When trying to build stout's tests on its own, I am hitting the following:
> {noformat}
> $ pwd
> /home/till/scratchpad/mesos/3rdparty/stout
> $ bootstrap
> $ mkdir build
> $ cd build/
> $ ../configure
> $ make check
> [...]
> ../tests/bytes_tests.cpp:13:25: fatal error: gtest/gtest.h: No such file or
> directory
> compilation terminated.
> Makefile:766: recipe for target 'stout_tests-bytes_tests.o' failed
> make[2]: *** [stout_tests-bytes_tests.o] Error 1
> make[2]: *** Waiting for unfinished jobs
> ../tests/base64_tests.cpp:13:25: fatal error: gtest/gtest.h: No such file or
> directory
> compilation terminated.
> ../tests/bits_tests.cpp:13:25: fatal error: gtest/gtest.h: No such file or
> directory
> compilation terminated.
> Makefile:738: recipe for target 'stout_tests-base64_tests.o' failed
> make[2]: *** [stout_tests-base64_tests.o] Error 1
> ../tests/duration_tests.cpp:13:25: fatal error: gtest/gtest.h: No such file
> or directory
> compilation terminated.
> Makefile:752: recipe for target 'stout_tests-bits_tests.o' failed
> make[2]: *** [stout_tests-bits_tests.o] Error 1
> Makefile:794: recipe for target 'stout_tests-duration_tests.o' failed
> make[2]: *** [stout_tests-duration_tests.o] Error 1
> ../tests/adaptor_tests.cpp:15:25: fatal error: gtest/gtest.h: No such file or
> directory
> compilation terminated.
> Makefile:724: recipe for target 'stout_tests-adaptor_tests.o' failed
> make[2]: *** [stout_tests-adaptor_tests.o] Error 1
> ../tests/cache_tests.cpp:15:25: fatal error: gtest/gtest.h: No such file or
> directory
> compilation terminated.
> Makefile:780: recipe for target 'stout_tests-cache_tests.o' failed
> make[2]: *** [stout_tests-cache_tests.o] Error 1
> make[2]: Leaving directory '/home/till/scratchpad/mesos/3rdparty/stout/build'
> Makefile:1706: recipe for target 'check-am' failed
> make[1]: *** [check-am] Error 2
> make[1]: Leaving directory '/home/till/scratchpad/mesos/3rdparty/stout/build'
> Makefile:1418: recipe for target 'check-recursive' failed
> make: *** [check-recursive] Error 1
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-5415) bootstrap of libprocess fails.
[
https://issues.apache.org/jira/browse/MESOS-5415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kapil Arya reassigned MESOS-5415:
-
Assignee: Kapil Arya (was: haosdent)
> bootstrap of libprocess fails.
> --
>
> Key: MESOS-5415
> URL: https://issues.apache.org/jira/browse/MESOS-5415
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 0.29.0
>Reporter: Till Toenshoff
>Assignee: Kapil Arya
>
> When trying to build libprocess on its own, I am hitting the following:
> {noformat}
> $ pwd
> /home/till/scratchpad/mesos/3rdparty/libprocess
> $ ./bootstrap
> […]
> configure.ac:64: error: required file '3rdparty/gmock_sources.cc.in' not found
> {noformat}
> So the standalone {{configure.ac}} still tries to locate
> {{gmock_source.cc.in}} in a subfolder called {{3rdparty}} while it should
> actually try to locate it in its parent folder.
> {noformat}
> $ ll /home/till/scratchpad/mesos/3rdparty/gmock_sources.cc.in
> -rw-rw-r--. 1 till till 730 May 19 13:22
> /home/till/scratchpad/mesos/3rdparty/gmock_sources.cc.in
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5465) Container image as a volume source should also include image manifest.
Jie Yu created MESOS-5465: - Summary: Container image as a volume source should also include image manifest. Key: MESOS-5465 URL: https://issues.apache.org/jira/browse/MESOS-5465 Project: Mesos Issue Type: Bug Reporter: Jie Yu Currently, if a user specifies the source of a volume to be an image (e.g., Docker image), we only prepare the rootfs and mount it at 'container_path' in the container. However, the rootfs itself is not sufficient to allow the executor to launch the docker container. We need the docker manifest as well to get the env, entry point, cmd information. One solutions is to make container_path a directory containing two things: 1) rootfs, 2) manifest. But this is a breaking change, we might need to introduce a deprecation cycle for that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5464) The max number of completed executors for a mesos slave should be configurable
[ https://issues.apache.org/jira/browse/MESOS-5464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilbert Song updated MESOS-5464: Assignee: (was: Kevin Devroede) > The max number of completed executors for a mesos slave should be configurable > -- > > Key: MESOS-5464 > URL: https://issues.apache.org/jira/browse/MESOS-5464 > Project: Mesos > Issue Type: Improvement >Reporter: Kevin Johnstone >Priority: Trivial > Original Estimate: 1h > Remaining Estimate: 1h > > The number of completed executors per framework should be configurable. > Frameworks such as Chronos make one executor per tasks and the default of 150 > executors makes sandbox logs inaccessible through the mesos UI very quickly, > far before the specified timeout for garbage collection for a task. > https://github.com/apache/mesos/blob/4db9b630cc67f706a8814436309ab589cbaa64fc/src/slave/constants.hpp#L64 > shows where the constant is currently set. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5464) The max number of completed executors for a mesos slave should be configurable
[ https://issues.apache.org/jira/browse/MESOS-5464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilbert Song updated MESOS-5464: Assignee: Kevin Devroede > The max number of completed executors for a mesos slave should be configurable > -- > > Key: MESOS-5464 > URL: https://issues.apache.org/jira/browse/MESOS-5464 > Project: Mesos > Issue Type: Improvement >Reporter: Kevin Johnstone >Assignee: Kevin Devroede >Priority: Trivial > Original Estimate: 1h > Remaining Estimate: 1h > > The number of completed executors per framework should be configurable. > Frameworks such as Chronos make one executor per tasks and the default of 150 > executors makes sandbox logs inaccessible through the mesos UI very quickly, > far before the specified timeout for garbage collection for a task. > https://github.com/apache/mesos/blob/4db9b630cc67f706a8814436309ab589cbaa64fc/src/slave/constants.hpp#L64 > shows where the constant is currently set. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5464) The max number of completed executors for a mesos slave should be configurable
Kevin Johnstone created MESOS-5464: -- Summary: The max number of completed executors for a mesos slave should be configurable Key: MESOS-5464 URL: https://issues.apache.org/jira/browse/MESOS-5464 Project: Mesos Issue Type: Improvement Reporter: Kevin Johnstone Priority: Trivial The number of completed executors per framework should be configurable. Frameworks such as Chronos make one executor per tasks and the default of 150 executors makes sandbox logs inaccessible through the mesos UI very quickly, far before the specified timeout for garbage collection for a task. https://github.com/apache/mesos/blob/4db9b630cc67f706a8814436309ab589cbaa64fc/src/slave/constants.hpp#L64 shows where the constant is currently set. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5430) Design the improvement of the home page of mesos.apache.org
[ https://issues.apache.org/jira/browse/MESOS-5430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15302828#comment-15302828 ] Jonathan Manalus commented on MESOS-5430: - [~haosd...@gmail.com] - It's looking great. I believe these would be the last changes to the page. Small Tweaks: When you hover the button or the changlog link in the header. Can you make them change to #4EADE2 on hover http://cl.ly/1m1K260M2s0Q Mobile - Can you add 48px margin-bottom below each point http://cl.ly/2A293Z0R0420 Mobile - Can you increase the bottom margin between the Twitter buttons, and the footer text to 32px http://cl.ly/1o0C2t1Y2O3s > Design the improvement of the home page of mesos.apache.org > --- > > Key: MESOS-5430 > URL: https://issues.apache.org/jira/browse/MESOS-5430 > Project: Mesos > Issue Type: Improvement > Components: project website >Reporter: Vinod Kone >Assignee: Jonathan Manalus > Attachments: page_1.png, page_2.png > > > The idea is to come up with a minimal improvement for the design of the home > page of mesos.apache.org. > Proposed Redesign: https://invis.io/CV7DZF1JW#/159898819_Mesos-apache-org -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5463) mesos::internal::Files gets in an invalid state if the paths "/" and "" are attached
Alexander Rojas created MESOS-5463:
--
Summary: mesos::internal::Files gets in an invalid state if the
paths "/" and "" are attached
Key: MESOS-5463
URL: https://issues.apache.org/jira/browse/MESOS-5463
Project: Mesos
Issue Type: Bug
Components: technical debt
Affects Versions: 0.29.0
Reporter: Alexander Rojas
Priority: Trivial
Part of the code for attaching a path to {{mesos::internal::Files}} includes
removing [trailing
slashes|https://github.com/apache/mesos/blob/6ce476461f0fedfb4ed4e40c15f25bb79a39b0f3/src/files/files.cpp#L238].
Which leads to attaching "{{/}}" and "{{}}" equivalent and could lead to
rewriting one with the other:
{code}
files.attach("/tmp", "/"); // Request to
http://localhost:5050/files/browse?path=/ returns /tmp
files.attach("/usr/dev", ""); // Request to
http://localhost:5050/files/browse?path=/ returns /usr/dev
{code}
Note that the empty path cannot be queried since it results in the invalid
request {{http://localhost:5050/files/browse?path=}}.
Given the last statement, probably the easiest solution is to forbid attaching
the empty path.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-5173) Allow master/agent to take multiple modules manifest files
[ https://issues.apache.org/jira/browse/MESOS-5173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15276618#comment-15276618 ] Kapil Arya edited comment on MESOS-5173 at 5/26/16 5:59 PM: Added RRs: https://reviews.apache.org/r/47123 : Added --modules_dir flag https://reviews.apache.org/r/47905 : Test case added. https://reviews.apache.org/r/47906 : Documentation updates. was (Author: karya): Added RR: https://reviews.apache.org/r/47123/ > Allow master/agent to take multiple modules manifest files > -- > > Key: MESOS-5173 > URL: https://issues.apache.org/jira/browse/MESOS-5173 > Project: Mesos > Issue Type: Task >Reporter: Kapil Arya >Assignee: Kapil Arya >Priority: Blocker > Labels: mesosphere > Fix For: 0.29.0 > > > When loading multiple modules into master/agent, one has to merge all module > metadata (library name, module name, parameters, etc.) into a single json > file which is then passed on to the --modules flag. This quickly becomes > cumbersome especially if the modules are coming from different > vendors/developers. > An alternate would be to allow multiple invocations of --modules flag that > can then be passed on to the module manager. That way, each flag corresponds > to just one module library and modules from that library. > Another approach is to create a new flag (e.g., --modules-dir) that contains > a path to a directory that would contain multiple json files. One can think > of it as an analogous to systemd units. The operator that drops a new file > into this directory and the file would automatically be picked up by the > master/agent module manager. Further, the naming scheme can also be inherited > to prefix the filename with an "NN_" to signify oad order. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5170) Adapt json creation for authorization based endpoint filtering.
[ https://issues.apache.org/jira/browse/MESOS-5170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam B updated MESOS-5170: -- Sprint: Mesosphere Sprint 36 > Adapt json creation for authorization based endpoint filtering. > --- > > Key: MESOS-5170 > URL: https://issues.apache.org/jira/browse/MESOS-5170 > Project: Mesos > Issue Type: Improvement >Reporter: Joerg Schad >Assignee: Joerg Schad > Labels: authorization, mesosphere, security > Fix For: 0.29.0 > > > For authorization based endpoint filtering we need to adapt the json endpoint > creation as discussed in MESOS-4931. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5335) Add authorization to GET /weights.
[ https://issues.apache.org/jira/browse/MESOS-5335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam B updated MESOS-5335: -- Sprint: Mesosphere Sprint 36 > Add authorization to GET /weights. > -- > > Key: MESOS-5335 > URL: https://issues.apache.org/jira/browse/MESOS-5335 > Project: Mesos > Issue Type: Improvement > Components: master, security >Reporter: Adam B >Assignee: zhou xing > Labels: mesosphere, security > Fix For: 0.29.0 > > > We already authorize which http users can update weights for particular > roles, but even knowing of the existence of these roles (let alone their > weights) may be sensitive information. We should add authz around GET > operations on /weights. > Easy option: GET_ENDPOINT_WITH_PATH /weights > - Pro: No new verb > - Con: All or nothing > Complex option: GET_WEIGHTS_WITH_ROLE > - Pro: Filters contents based on roles the user is authorized to see > - Con: More authorize calls (one per role in each /weights request) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5459) Update RUN_TASK_WITH_USER to use additional metadata
[ https://issues.apache.org/jira/browse/MESOS-5459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam B updated MESOS-5459: -- Sprint: Mesosphere Sprint 36 > Update RUN_TASK_WITH_USER to use additional metadata > > > Key: MESOS-5459 > URL: https://issues.apache.org/jira/browse/MESOS-5459 > Project: Mesos > Issue Type: Improvement > Components: security >Reporter: Adam B >Assignee: Benjamin Bannier > Labels: mesosphere, security > Fix For: 0.29.0 > > > Currently, the `authorization::Action` `RUN_TASK_WITH_USER` will pass the > user as its `Object.value` string, but some authorizers may want to make > authorization decisions based on additional task attributes, like role, > resources, labels, container type, etc. > We should create a new Action `RUN_TASK` that passes FrameworkInfo and > TaskInfo in its Object, and the LocalAuthorizer's RunTaskWithUser ACL can be > implemented using the user found in TaskInfo/FrameworkInfo. > We may need to leave the old _WITH_USER action around, but it's arguable > whether we should call the authorizer once for RUN_TASK and once for > RUN_TASK_WITH_USER, or only use the new action and deprecate the old one? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5279) DRF sorter add/activate doesn't check if it's adding a duplicate entry
[
https://issues.apache.org/jira/browse/MESOS-5279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15302494#comment-15302494
]
Yan Xu commented on MESOS-5279:
---
[~jvanremoortere] I updated review comments, can you take a another look?
> DRF sorter add/activate doesn't check if it's adding a duplicate entry
> --
>
> Key: MESOS-5279
> URL: https://issues.apache.org/jira/browse/MESOS-5279
> Project: Mesos
> Issue Type: Bug
> Components: allocation
>Reporter: Yan Xu
>Assignee: Yan Xu
>
> Currently the sorter relies on the caller to make sure the sorter is in a
> good state when add/activate is called. It's not defensive against caller
> mistakes as it should be. It's never an acceptable result if duplicates are
> added to {{DRFSorter::clients}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5397) Slave/Agent Rename Phase 1: Update terms in the website
[ https://issues.apache.org/jira/browse/MESOS-5397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent updated MESOS-5397: Description: The following files need to be updated site/source/index.html.md was: The following files need to be updated site/source/index.html.md site/README.md > Slave/Agent Rename Phase 1: Update terms in the website > --- > > Key: MESOS-5397 > URL: https://issues.apache.org/jira/browse/MESOS-5397 > Project: Mesos > Issue Type: Bug > Components: project website >Reporter: Vinod Kone >Assignee: haosdent > > The following files need to be updated > site/source/index.html.md -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-5407) Slave/Agent rename: diagrams in docs
[ https://issues.apache.org/jira/browse/MESOS-5407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Guo reassigned MESOS-5407: -- Assignee: Jay Guo > Slave/Agent rename: diagrams in docs > > > Key: MESOS-5407 > URL: https://issues.apache.org/jira/browse/MESOS-5407 > Project: Mesos > Issue Type: Bug > Components: documentation >Reporter: Jay Guo >Assignee: Jay Guo >Priority: Minor > > Rename 'slave' in diagrams -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5424) Update the style of code under website folder to match other exist source code
[ https://issues.apache.org/jira/browse/MESOS-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] haosdent updated MESOS-5424: Attachment: website_pc.gif website_mobile.gif > Update the style of code under website folder to match other exist source code > -- > > Key: MESOS-5424 > URL: https://issues.apache.org/jira/browse/MESOS-5424 > Project: Mesos > Issue Type: Improvement >Reporter: haosdent >Assignee: haosdent >Priority: Minor > Attachments: website_mobile.gif, website_pc.gif > > > Because we migrate the website from svn before, some parts of it are > inconsistent with our other code in webui and docs folder. We need to update > to avoid confusing in following website development. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5173) Allow master/agent to take multiple modules manifest files
[ https://issues.apache.org/jira/browse/MESOS-5173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kapil Arya updated MESOS-5173: -- Priority: Blocker (was: Major) > Allow master/agent to take multiple modules manifest files > -- > > Key: MESOS-5173 > URL: https://issues.apache.org/jira/browse/MESOS-5173 > Project: Mesos > Issue Type: Task >Reporter: Kapil Arya >Assignee: Kapil Arya >Priority: Blocker > Labels: mesosphere > Fix For: 0.29.0 > > > When loading multiple modules into master/agent, one has to merge all module > metadata (library name, module name, parameters, etc.) into a single json > file which is then passed on to the --modules flag. This quickly becomes > cumbersome especially if the modules are coming from different > vendors/developers. > An alternate would be to allow multiple invocations of --modules flag that > can then be passed on to the module manager. That way, each flag corresponds > to just one module library and modules from that library. > Another approach is to create a new flag (e.g., --modules-dir) that contains > a path to a directory that would contain multiple json files. One can think > of it as an analogous to systemd units. The operator that drops a new file > into this directory and the file would automatically be picked up by the > master/agent module manager. Further, the naming scheme can also be inherited > to prefix the filename with an "NN_" to signify oad order. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5064) Remove default value for the agent `work_dir`
[
https://issues.apache.org/jira/browse/MESOS-5064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Harutyunyan updated MESOS-5064:
-
Fix Version/s: 0.29.0
> Remove default value for the agent `work_dir`
> -
>
> Key: MESOS-5064
> URL: https://issues.apache.org/jira/browse/MESOS-5064
> Project: Mesos
> Issue Type: Bug
>Reporter: Artem Harutyunyan
>Assignee: Greg Mann
> Fix For: 0.29.0
>
>
> Following a crash report from the user we need to be more explicit about the
> dangers of using {{/tmp}} as agent {{work_dir}}. In addition, we can remove
> the default value for the {{\-\-work_dir}} flag, forcing users to explicitly
> set the work directory for the agent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5394) Rename isolator name 'xfs/disk' and 'posix/disk' to 'disk/xfs' and 'disk/du'
[ https://issues.apache.org/jira/browse/MESOS-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yan Xu updated MESOS-5394: -- Shepherd: Jie Yu Affects Version/s: 0.29.0 Priority: Blocker (was: Major) Strictly speaking only the first patch is a blocker for 0.29.0 but let's see if we can also get the second patch in too. > Rename isolator name 'xfs/disk' and 'posix/disk' to 'disk/xfs' and 'disk/du' > > > Key: MESOS-5394 > URL: https://issues.apache.org/jira/browse/MESOS-5394 > Project: Mesos > Issue Type: Task > Components: containerization >Affects Versions: 0.29.0 >Reporter: Yan Xu >Assignee: Yan Xu >Priority: Blocker > Fix For: 0.29.0 > > > See comments from MESOS-4828, the XFS isolator is named "xfs/disk" for > consistency with "posix/disk". However 'disk/xfs' and 'disk/du' are more in > line with the isolator [naming patterns we are > adopting|https://github.com/apache/mesos/blob/a4d05ad108d0f4c1354f72057332047416eefbe0/src/slave/containerizer/mesos/containerizer.cpp#L225] > going forward. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5453) CNI should not store subnet of address in NetworkInfo
[ https://issues.apache.org/jira/browse/MESOS-5453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Harutyunyan updated MESOS-5453: - Assignee: Dan Osborne > CNI should not store subnet of address in NetworkInfo > - > > Key: MESOS-5453 > URL: https://issues.apache.org/jira/browse/MESOS-5453 > Project: Mesos > Issue Type: Bug >Reporter: Dan Osborne >Assignee: Dan Osborne > Labels: mesosphere > Fix For: 0.29.0 > > > When the CNI isolator executes the CNI plugin, that CNI plugin will return an > IP Address and Subnet (192.168.0.1/32). Mesos should strip the subnet before > storing the address in the Task.NetworkInfo.IPAddress. > Reason being - most current mesos components are not expecting a subnet in > the Task's NetworkInfo.IPAddress, and instead expect just the IP address. > This can cause errors in those components, such as Mesos-DNS failing to > return a NetworkInfo address (and instead defaulting to the next configured > IPSource), and Marathon generating invalid links to tasks (as it includes /32 > in the link) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5394) Rename isolator name 'xfs/disk' and 'posix/disk' to 'disk/xfs' and 'disk/du'
[ https://issues.apache.org/jira/browse/MESOS-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15302333#comment-15302333 ] Yan Xu commented on MESOS-5394: --- [~jieyu] Can you shepherd it? > Rename isolator name 'xfs/disk' and 'posix/disk' to 'disk/xfs' and 'disk/du' > > > Key: MESOS-5394 > URL: https://issues.apache.org/jira/browse/MESOS-5394 > Project: Mesos > Issue Type: Task > Components: containerization >Reporter: Yan Xu >Assignee: Yan Xu > > See comments from MESOS-4828, the XFS isolator is named "xfs/disk" for > consistency with "posix/disk". However 'disk/xfs' and 'disk/du' are more in > line with the isolator [naming patterns we are > adopting|https://github.com/apache/mesos/blob/a4d05ad108d0f4c1354f72057332047416eefbe0/src/slave/containerizer/mesos/containerizer.cpp#L225] > going forward. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5216) Document docker volume driver isolator.
[ https://issues.apache.org/jira/browse/MESOS-5216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jie Yu updated MESOS-5216: -- Story Points: 5 > Document docker volume driver isolator. > --- > > Key: MESOS-5216 > URL: https://issues.apache.org/jira/browse/MESOS-5216 > Project: Mesos > Issue Type: Bug > Components: containerization >Reporter: Gilbert Song >Assignee: Guangya Liu > Labels: documentaion, mesosphere > Fix For: 0.29.0 > > > Should include the followings: > 1. What features (driver options) are supported in docker volume driver > isolator. > 2. How to use docker volume driver isolator. > *related agent flags introduction and usage. > *isolator dependency clarification (e.g., filesystem/linux). > *related driver daemon preprocess. > *volumes pre-specified by users and volume cleanup. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5277) Need to add REMOVE semantics to the copy backend
[ https://issues.apache.org/jira/browse/MESOS-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilbert Song updated MESOS-5277: Story Points: 5 > Need to add REMOVE semantics to the copy backend > > > Key: MESOS-5277 > URL: https://issues.apache.org/jira/browse/MESOS-5277 > Project: Mesos > Issue Type: Bug > Components: containerization > Environment: linux >Reporter: Avinash Sridharan >Assignee: Gilbert Song > Labels: mesosphere > Fix For: 0.29.0 > > > Some Dockerfiles run the `rm` command to remove files from the base image > using the "RUN" directive in the Dockerfile. An example can be found here: > https://github.com/ngineered/nginx-php-fpm.git > In the final rootfs the removed files should not be present. Presence of > these files in the final image can make the container misbehave. For example, > the nginx-php-fpm docker image that is referenced tries to remove the default > nginx config and replaces it with its own config to point to a different HTML > root. If the default nginx config is still present after the building the > image, nginx will start pointing to a different HTML root than the one set in > the Dockerfile. > Currently the copy backend cannot handle removal of files from intermediate > layers. This can cause issues with docker images built using a Dockerfile > similar to the one listed here. Hence, we need to add REMOVE semantics to the > copy backend. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-5394) Rename isolator name 'xfs/disk' and 'posix/disk' to 'disk/xfs' and 'disk/du'
[ https://issues.apache.org/jira/browse/MESOS-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yan Xu reassigned MESOS-5394: - Assignee: Yan Xu > Rename isolator name 'xfs/disk' and 'posix/disk' to 'disk/xfs' and 'disk/du' > > > Key: MESOS-5394 > URL: https://issues.apache.org/jira/browse/MESOS-5394 > Project: Mesos > Issue Type: Task > Components: containerization >Reporter: Yan Xu >Assignee: Yan Xu > > See comments from MESOS-4828, the XFS isolator is named "xfs/disk" for > consistency with "posix/disk". However 'disk/xfs' and 'disk/du' are more in > line with the isolator [naming patterns we are > adopting|https://github.com/apache/mesos/blob/a4d05ad108d0f4c1354f72057332047416eefbe0/src/slave/containerizer/mesos/containerizer.cpp#L225] > going forward. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5462) Re-organize isolator hierarchy
Alex Clemmer created MESOS-5462: --- Summary: Re-organize isolator hierarchy Key: MESOS-5462 URL: https://issues.apache.org/jira/browse/MESOS-5462 Project: Mesos Issue Type: Bug Components: isolation Reporter: Alex Clemmer Assignee: Alex Clemmer Right now the Windows isolators are basically direct copies of their POSIX counterparts. In the future, we want to have platform-independent base classes, with POSIX and Windows implementations inheriting. For now, we leave the Windows implementation inheriting from POSIX. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5461) Add Windows support for persistent volumes.
[ https://issues.apache.org/jira/browse/MESOS-5461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Clemmer updated MESOS-5461: Description: Right now the persistent volumes code in the POSIX isolators is `#ifdef`'d out for Windows compilations. This is because the Windows isolators take a dependency on the POSIX isolators, but Windows doesn't support `os::chown`. Since this protects the invariant that persistent volumes be owned by one task at a time, we currently choose to disable the whole thing for now. At a later date we will need to come back and revisit this. was: Right now there is some code in the POSIX isolators that is `#ifdef`'d out for Windows compilations. This is because the Windows isolators take a dependency on the POSIX isolators, but Windows doesn't support `os::chown`. In the future, we should either refactor the Windows isolators to not depend on the POSIX isolators, or factor out the `os::stat` code that doesn't work on Windows. > Add Windows support for persistent volumes. > --- > > Key: MESOS-5461 > URL: https://issues.apache.org/jira/browse/MESOS-5461 > Project: Mesos > Issue Type: Bug > Components: isolation >Reporter: Alex Clemmer >Assignee: Alex Clemmer > Labels: agent, mesos, mesosphere > > Right now the persistent volumes code in the POSIX isolators is `#ifdef`'d > out for Windows compilations. > This is because the Windows isolators take a dependency on the POSIX > isolators, but Windows doesn't support `os::chown`. Since this protects the > invariant that persistent volumes be owned by one task at a time, we > currently choose to disable the whole thing for now. At a later date we will > need to come back and revisit this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5461) Add Windows support for persistent volumes.
[ https://issues.apache.org/jira/browse/MESOS-5461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Clemmer updated MESOS-5461: Summary: Add Windows support for persistent volumes. (was: Refactor the Windows and POSIX isolators into sets of common logic.) > Add Windows support for persistent volumes. > --- > > Key: MESOS-5461 > URL: https://issues.apache.org/jira/browse/MESOS-5461 > Project: Mesos > Issue Type: Bug > Components: isolation >Reporter: Alex Clemmer >Assignee: Alex Clemmer > Labels: agent, mesos, mesosphere > > Right now there is some code in the POSIX isolators that is `#ifdef`'d out > for Windows compilations. > This is because the Windows isolators take a dependency on the POSIX > isolators, but Windows doesn't support `os::chown`. > In the future, we should either refactor the Windows isolators to not depend > on the POSIX isolators, or factor out the `os::stat` code that doesn't work > on Windows. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5461) Refactor the Windows and POSIX isolators into sets of common logic.
[ https://issues.apache.org/jira/browse/MESOS-5461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Clemmer updated MESOS-5461: Description: Right now there is some code in the POSIX isolators that is `#ifdef`'d out for Windows compilations. This is because the Windows isolators take a dependency on the POSIX isolators, but Windows doesn't support `os::chown`. In the future, we should either refactor the Windows isolators to not depend on the POSIX isolators, or factor out the `os::stat` code that doesn't work on Windows. was: Right now there is some code in the POSIX isolators that is `#ifdef`'d out for Windows compilations. This is because the Windows isolators take a dependency on the POSIX isolators, but Windows doesn't support `os::stat`. In the future, we should either refactor the Windows isolators to not depend on the POSIX isolators, or factor out the `os::stat` code that doesn't work on Windows. > Refactor the Windows and POSIX isolators into sets of common logic. > --- > > Key: MESOS-5461 > URL: https://issues.apache.org/jira/browse/MESOS-5461 > Project: Mesos > Issue Type: Bug > Components: isolation >Reporter: Alex Clemmer >Assignee: Alex Clemmer > Labels: agent, mesos, mesosphere > > Right now there is some code in the POSIX isolators that is `#ifdef`'d out > for Windows compilations. > This is because the Windows isolators take a dependency on the POSIX > isolators, but Windows doesn't support `os::chown`. > In the future, we should either refactor the Windows isolators to not depend > on the POSIX isolators, or factor out the `os::stat` code that doesn't work > on Windows. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5461) Refactor the Windows and POSIX isolators into sets of common logic.
Alex Clemmer created MESOS-5461: --- Summary: Refactor the Windows and POSIX isolators into sets of common logic. Key: MESOS-5461 URL: https://issues.apache.org/jira/browse/MESOS-5461 Project: Mesos Issue Type: Bug Components: isolation Reporter: Alex Clemmer Assignee: Alex Clemmer Right now there is some code in the POSIX isolators that is `#ifdef`'d out for Windows compilations. This is because the Windows isolators take a dependency on the POSIX isolators, but Windows doesn't support `os::stat`. In the future, we should either refactor the Windows isolators to not depend on the POSIX isolators, or factor out the `os::stat` code that doesn't work on Windows. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5460) Add HDFS support in Windows builds.
Alex Clemmer created MESOS-5460: --- Summary: Add HDFS support in Windows builds. Key: MESOS-5460 URL: https://issues.apache.org/jira/browse/MESOS-5460 Project: Mesos Issue Type: Bug Components: slave Reporter: Alex Clemmer Assignee: Alex Clemmer Right now we have a bunch of #ifdefs throughout the codebase around the HDFS code, because Windows doesn't support it. We should explore adding support for (e.g.) fetching from HDFS. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5452) Agent modules should be initialized before all components except firewall.
[ https://issues.apache.org/jira/browse/MESOS-5452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avinash Sridharan updated MESOS-5452: - Sprint: (was: Mesosphere Sprint 35) > Agent modules should be initialized before all components except firewall. > -- > > Key: MESOS-5452 > URL: https://issues.apache.org/jira/browse/MESOS-5452 > Project: Mesos > Issue Type: Improvement > Components: containerization > Environment: Linux >Reporter: Avinash Sridharan >Assignee: Avinash Sridharan > Labels: mesosphere > Fix For: 0.29.0 > > > On Mesos Agents Anonymous modules should not have any dependencies, by > design, on any other Mesos components. This implies that Anonymous modules > should be initialized before all other Mesos components other than > `Firewall`. The dependency on `Firewall` is primarily to enforce any policies > to secure endpoints that might be owned by the Anonymous module. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5456) Master anonymous modules should initialized before any other components.
[ https://issues.apache.org/jira/browse/MESOS-5456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avinash Sridharan updated MESOS-5456: - Sprint: (was: Mesosphere Sprint 35) > Master anonymous modules should initialized before any other components. > > > Key: MESOS-5456 > URL: https://issues.apache.org/jira/browse/MESOS-5456 > Project: Mesos > Issue Type: Improvement > Environment: Linux >Reporter: Avinash Sridharan >Assignee: Avinash Sridharan > Labels: mesosphere > Fix For: 0.29.0 > > > Anonymous modules on the Master are by design supposed to be independent of > any Mesos components. However, there might be a dependency in the reverse > direction. For e.g., Anonymous modules might want to influence the behavior > of Mesos components (say by generating configuration, that might be consumed > later by the components). > The Anonymous modules on the Master therefore need to be initialized before > other Mesos components. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5459) Update RUN_TASK_WITH_USER to use additional metadata
Adam B created MESOS-5459: - Summary: Update RUN_TASK_WITH_USER to use additional metadata Key: MESOS-5459 URL: https://issues.apache.org/jira/browse/MESOS-5459 Project: Mesos Issue Type: Improvement Components: security Reporter: Adam B Fix For: 0.29.0 Currently, the `authorization::Action` `RUN_TASK_WITH_USER` will pass the user as its `Object.value` string, but some authorizers may want to make authorization decisions based on additional task attributes, like role, resources, labels, container type, etc. We should create a new Action `RUN_TASK` that passes FrameworkInfo and TaskInfo in its Object, and the LocalAuthorizer's RunTaskWithUser ACL can be implemented using the user found in TaskInfo/FrameworkInfo. We may need to leave the old _WITH_USER action around, but it's arguable whether we should call the authorizer once for RUN_TASK and once for RUN_TASK_WITH_USER, or only use the new action and deprecate the old one? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
