[jira] [Commented] (MESOS-4957) Typo in Mesos portal
[ https://issues.apache.org/jira/browse/MESOS-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15197134#comment-15197134 ] Yongqiao Wang commented on MESOS-4957: -- [~adam-mesos], can you shepherd for this? > Typo in Mesos portal > > > Key: MESOS-4957 > URL: https://issues.apache.org/jira/browse/MESOS-4957 > Project: Mesos > Issue Type: Bug >Reporter: Yongqiao Wang >Assignee: Yongqiao Wang > Attachments: $3E85CFC7C5E68241.jpg > > > See the attachment for the details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4957) Typo in Mesos portal
[ https://issues.apache.org/jira/browse/MESOS-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yongqiao Wang updated MESOS-4957: - Attachment: $3E85CFC7C5E68241.jpg > Typo in Mesos portal > > > Key: MESOS-4957 > URL: https://issues.apache.org/jira/browse/MESOS-4957 > Project: Mesos > Issue Type: Bug >Reporter: Yongqiao Wang >Assignee: Yongqiao Wang > Attachments: $3E85CFC7C5E68241.jpg > > > See the attachment for the details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4957) Typo in Mesos portal
[ https://issues.apache.org/jira/browse/MESOS-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yongqiao Wang updated MESOS-4957: - Description: See the attachment for the detais. > Typo in Mesos portal > > > Key: MESOS-4957 > URL: https://issues.apache.org/jira/browse/MESOS-4957 > Project: Mesos > Issue Type: Bug >Reporter: Yongqiao Wang >Assignee: Yongqiao Wang > > See the attachment for the detais. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4957) Typo in Mesos portal
[ https://issues.apache.org/jira/browse/MESOS-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yongqiao Wang updated MESOS-4957: - Description: See the attachment for the details. (was: See the attachment for the detais.) > Typo in Mesos portal > > > Key: MESOS-4957 > URL: https://issues.apache.org/jira/browse/MESOS-4957 > Project: Mesos > Issue Type: Bug >Reporter: Yongqiao Wang >Assignee: Yongqiao Wang > > See the attachment for the details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4932) Propose Design for Authorization based filtering for endpoints.
[ https://issues.apache.org/jira/browse/MESOS-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15197131#comment-15197131 ] Adam B commented on MESOS-4932: --- In the future of hierarchical multi-role frameworks, the VIEW_TASKINFOS_WITH_ROLE "foo/appgroup/app" can represent finer-grained project scope, rather than requiring a user/group to share all their tasks with any user/group that needs access to a single task. > Propose Design for Authorization based filtering for endpoints. > --- > > Key: MESOS-4932 > URL: https://issues.apache.org/jira/browse/MESOS-4932 > Project: Mesos > Issue Type: Task > Components: security >Reporter: Joerg Schad >Assignee: Joerg Schad > Labels: authorization, mesosphere, security > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-4957) Typo in Mesos portal
Yongqiao Wang created MESOS-4957: Summary: Typo in Mesos portal Key: MESOS-4957 URL: https://issues.apache.org/jira/browse/MESOS-4957 Project: Mesos Issue Type: Bug Reporter: Yongqiao Wang Assignee: Yongqiao Wang -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4902) Add authentication to remaining agent endpoints
[
https://issues.apache.org/jira/browse/MESOS-4902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam B updated MESOS-4902:
--
Assignee: (was: Greg Mann)
> Add authentication to remaining agent endpoints
> ---
>
> Key: MESOS-4902
> URL: https://issues.apache.org/jira/browse/MESOS-4902
> Project: Mesos
> Issue Type: Improvement
> Components: HTTP API
>Reporter: Greg Mann
> Labels: authentication, http, mesosphere, security
>
> In addition to the endpoints addressed by MESOS-4850 and MESOS-4951, the
> following endpoints would also benefit from HTTP authentication:
> * {{/profiler/*}}
> * {{/logging/toggle}}
> * {{/metrics/snapshot}}
> * {{/monitor/statistics}}
> * {{/system/stats.json}}
> Adding HTTP authentication to these endpoints is a bit more complicated: some
> endpoints are defined at the libprocess level, while others are defined in
> code that is shared by the master and agent.
> While working on MESOS-4850, it became apparent that since our tests use the
> same instance of libprocess for both master and agent, different default
> authentication realms must be used for master/agent so that HTTP
> authentication can be independently enabled/disabled for each.
> We should establish a mechanism for making an endpoint authenticated that
> allows us to:
> 1) Install an endpoint like {{/files}}, whose code is shared by the master
> and agent, with different authentication realms for the master and agent
> 2) Avoid hard-coding a default authentication realm into libprocess, to
> permit the use of different authentication realms for the master and agent
> and to keep application-level concerns from leaking into libprocess
> Another option would be to use a single default authentication realm and
> always enable or disable HTTP authentication for *both* the master and agent
> in tests. However, this wouldn't allow us to test scenarios where HTTP
> authentication is enabled on one but disabled on the other.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4902) Add authentication to remaining agent endpoints
[
https://issues.apache.org/jira/browse/MESOS-4902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam B updated MESOS-4902:
--
Sprint: (was: Mesosphere Sprint 31)
> Add authentication to remaining agent endpoints
> ---
>
> Key: MESOS-4902
> URL: https://issues.apache.org/jira/browse/MESOS-4902
> Project: Mesos
> Issue Type: Improvement
> Components: HTTP API
>Reporter: Greg Mann
>Assignee: Greg Mann
> Labels: authentication, http, mesosphere, security
>
> In addition to the endpoints addressed by MESOS-4850, the following endpoints
> would also benefit from HTTP authentication:
> * {{/files/*}}
> * {{/profiler/*}}
> * {{/logging/toggle}}
> * {{/metrics/snapshot}}
> * {{/monitor/statistics}}
> * {{/system/stats.json}}
> Adding HTTP authentication to these endpoints is a bit more complicated: some
> endpoints are defined at the libprocess level, while others are defined in
> code that is shared by the master and agent.
> While working on MESOS-4850, it became apparent that since our tests use the
> same instance of libprocess for both master and agent, different default
> authentication realms must be used for master/agent so that HTTP
> authentication can be independently enabled/disabled for each.
> We should establish a mechanism for making an endpoint authenticated that
> allows us to:
> 1) Install an endpoint like {{/files}}, whose code is shared by the master
> and agent, with different authentication realms for the master and agent
> 2) Avoid hard-coding a default authentication realm into libprocess, to
> permit the use of different authentication realms for the master and agent
> and to keep application-level concerns from leaking into libprocess
> Another option would be to use a single default authentication realm and
> always enable or disable HTTP authentication for *both* the master and agent
> in tests. However, this wouldn't allow us to test scenarios where HTTP
> authentication is enabled on one but disabled on the other.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4902) Add authentication to remaining agent endpoints
[
https://issues.apache.org/jira/browse/MESOS-4902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam B updated MESOS-4902:
--
Description:
In addition to the endpoints addressed by MESOS-4850 and MESOS-4951, the
following endpoints would also benefit from HTTP authentication:
* {{/profiler/*}}
* {{/logging/toggle}}
* {{/metrics/snapshot}}
* {{/monitor/statistics}}
* {{/system/stats.json}}
Adding HTTP authentication to these endpoints is a bit more complicated: some
endpoints are defined at the libprocess level, while others are defined in code
that is shared by the master and agent.
While working on MESOS-4850, it became apparent that since our tests use the
same instance of libprocess for both master and agent, different default
authentication realms must be used for master/agent so that HTTP authentication
can be independently enabled/disabled for each.
We should establish a mechanism for making an endpoint authenticated that
allows us to:
1) Install an endpoint like {{/files}}, whose code is shared by the master and
agent, with different authentication realms for the master and agent
2) Avoid hard-coding a default authentication realm into libprocess, to permit
the use of different authentication realms for the master and agent and to keep
application-level concerns from leaking into libprocess
Another option would be to use a single default authentication realm and always
enable or disable HTTP authentication for *both* the master and agent in tests.
However, this wouldn't allow us to test scenarios where HTTP authentication is
enabled on one but disabled on the other.
was:
In addition to the endpoints addressed by MESOS-4850, the following endpoints
would also benefit from HTTP authentication:
* {{/files/*}}
* {{/profiler/*}}
* {{/logging/toggle}}
* {{/metrics/snapshot}}
* {{/monitor/statistics}}
* {{/system/stats.json}}
Adding HTTP authentication to these endpoints is a bit more complicated: some
endpoints are defined at the libprocess level, while others are defined in code
that is shared by the master and agent.
While working on MESOS-4850, it became apparent that since our tests use the
same instance of libprocess for both master and agent, different default
authentication realms must be used for master/agent so that HTTP authentication
can be independently enabled/disabled for each.
We should establish a mechanism for making an endpoint authenticated that
allows us to:
1) Install an endpoint like {{/files}}, whose code is shared by the master and
agent, with different authentication realms for the master and agent
2) Avoid hard-coding a default authentication realm into libprocess, to permit
the use of different authentication realms for the master and agent and to keep
application-level concerns from leaking into libprocess
Another option would be to use a single default authentication realm and always
enable or disable HTTP authentication for *both* the master and agent in tests.
However, this wouldn't allow us to test scenarios where HTTP authentication is
enabled on one but disabled on the other.
> Add authentication to remaining agent endpoints
> ---
>
> Key: MESOS-4902
> URL: https://issues.apache.org/jira/browse/MESOS-4902
> Project: Mesos
> Issue Type: Improvement
> Components: HTTP API
>Reporter: Greg Mann
>Assignee: Greg Mann
> Labels: authentication, http, mesosphere, security
>
> In addition to the endpoints addressed by MESOS-4850 and MESOS-4951, the
> following endpoints would also benefit from HTTP authentication:
> * {{/profiler/*}}
> * {{/logging/toggle}}
> * {{/metrics/snapshot}}
> * {{/monitor/statistics}}
> * {{/system/stats.json}}
> Adding HTTP authentication to these endpoints is a bit more complicated: some
> endpoints are defined at the libprocess level, while others are defined in
> code that is shared by the master and agent.
> While working on MESOS-4850, it became apparent that since our tests use the
> same instance of libprocess for both master and agent, different default
> authentication realms must be used for master/agent so that HTTP
> authentication can be independently enabled/disabled for each.
> We should establish a mechanism for making an endpoint authenticated that
> allows us to:
> 1) Install an endpoint like {{/files}}, whose code is shared by the master
> and agent, with different authentication realms for the master and agent
> 2) Avoid hard-coding a default authentication realm into libprocess, to
> permit the use of different authentication realms for the master and agent
> and to keep application-level concerns from leaking into libprocess
> Another option would be to use a single default authentication realm and
> always enable or disable HTTP authentication for *both* the master and agent
> in
[jira] [Updated] (MESOS-4956) Add authentication to /files endpoints
[
https://issues.apache.org/jira/browse/MESOS-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam B updated MESOS-4956:
--
Description:
To protect access (authz) to master/agent logs as well as executor sandboxes,
we need authentication on the /files endpoints.
Adding HTTP authentication to these endpoints is a bit complicated since they
are defined in code that is shared by the master and agent.
While working on MESOS-4850, it became apparent that since our tests use the
same instance of libprocess for both master and agent, different default
authentication realms must be used for master/agent so that HTTP authentication
can be independently enabled/disabled for each.
We should establish a mechanism for making an endpoint authenticated that
allows us to:
1) Install an endpoint like {{/files}}, whose code is shared by the master and
agent, with different authentication realms for the master and agent
2) Avoid hard-coding a default authentication realm into libprocess, to permit
the use of different authentication realms for the master and agent and to keep
application-level concerns from leaking into libprocess
Another option would be to use a single default authentication realm and always
enable or disable HTTP authentication for *both* the master and agent in tests.
However, this wouldn't allow us to test scenarios where HTTP authentication is
enabled on one but disabled on the other.
was:
In addition to the endpoints addressed by MESOS-4850, the following endpoints
would also benefit from HTTP authentication:
* {{/files/*}}
* {{/profiler/*}}
* {{/logging/toggle}}
* {{/metrics/snapshot}}
* {{/monitor/statistics}}
* {{/system/stats.json}}
Adding HTTP authentication to these endpoints is a bit more complicated: some
endpoints are defined at the libprocess level, while others are defined in code
that is shared by the master and agent.
While working on MESOS-4850, it became apparent that since our tests use the
same instance of libprocess for both master and agent, different default
authentication realms must be used for master/agent so that HTTP authentication
can be independently enabled/disabled for each.
We should establish a mechanism for making an endpoint authenticated that
allows us to:
1) Install an endpoint like {{/files}}, whose code is shared by the master and
agent, with different authentication realms for the master and agent
2) Avoid hard-coding a default authentication realm into libprocess, to permit
the use of different authentication realms for the master and agent and to keep
application-level concerns from leaking into libprocess
Another option would be to use a single default authentication realm and always
enable or disable HTTP authentication for *both* the master and agent in tests.
However, this wouldn't allow us to test scenarios where HTTP authentication is
enabled on one but disabled on the other.
> Add authentication to /files endpoints
> --
>
> Key: MESOS-4956
> URL: https://issues.apache.org/jira/browse/MESOS-4956
> Project: Mesos
> Issue Type: Improvement
> Components: HTTP API
>Reporter: Greg Mann
>Assignee: Greg Mann
> Labels: authentication, http, mesosphere, security
>
> To protect access (authz) to master/agent logs as well as executor sandboxes,
> we need authentication on the /files endpoints.
> Adding HTTP authentication to these endpoints is a bit complicated since they
> are defined in code that is shared by the master and agent.
> While working on MESOS-4850, it became apparent that since our tests use the
> same instance of libprocess for both master and agent, different default
> authentication realms must be used for master/agent so that HTTP
> authentication can be independently enabled/disabled for each.
> We should establish a mechanism for making an endpoint authenticated that
> allows us to:
> 1) Install an endpoint like {{/files}}, whose code is shared by the master
> and agent, with different authentication realms for the master and agent
> 2) Avoid hard-coding a default authentication realm into libprocess, to
> permit the use of different authentication realms for the master and agent
> and to keep application-level concerns from leaking into libprocess
> Another option would be to use a single default authentication realm and
> always enable or disable HTTP authentication for *both* the master and agent
> in tests. However, this wouldn't allow us to test scenarios where HTTP
> authentication is enabled on one but disabled on the other.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-4956) Add authentication to /files endpoints
Adam B created MESOS-4956:
-
Summary: Add authentication to /files endpoints
Key: MESOS-4956
URL: https://issues.apache.org/jira/browse/MESOS-4956
Project: Mesos
Issue Type: Improvement
Components: HTTP API
Reporter: Greg Mann
Assignee: Greg Mann
In addition to the endpoints addressed by MESOS-4850, the following endpoints
would also benefit from HTTP authentication:
* {{/files/*}}
* {{/profiler/*}}
* {{/logging/toggle}}
* {{/metrics/snapshot}}
* {{/monitor/statistics}}
* {{/system/stats.json}}
Adding HTTP authentication to these endpoints is a bit more complicated: some
endpoints are defined at the libprocess level, while others are defined in code
that is shared by the master and agent.
While working on MESOS-4850, it became apparent that since our tests use the
same instance of libprocess for both master and agent, different default
authentication realms must be used for master/agent so that HTTP authentication
can be independently enabled/disabled for each.
We should establish a mechanism for making an endpoint authenticated that
allows us to:
1) Install an endpoint like {{/files}}, whose code is shared by the master and
agent, with different authentication realms for the master and agent
2) Avoid hard-coding a default authentication realm into libprocess, to permit
the use of different authentication realms for the master and agent and to keep
application-level concerns from leaking into libprocess
Another option would be to use a single default authentication realm and always
enable or disable HTTP authentication for *both* the master and agent in tests.
However, this wouldn't allow us to test scenarios where HTTP authentication is
enabled on one but disabled on the other.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-4951) Enable actors to set an existing endpoint's authentication realm
[
https://issues.apache.org/jira/browse/MESOS-4951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam B updated MESOS-4951:
--
Labels: authentication http mesosphere security (was: authentication http
mesosphere)
> Enable actors to set an existing endpoint's authentication realm
>
>
> Key: MESOS-4951
> URL: https://issues.apache.org/jira/browse/MESOS-4951
> Project: Mesos
> Issue Type: Bug
> Components: libprocess, slave
>Reporter: Greg Mann
>Assignee: Greg Mann
> Labels: authentication, http, mesosphere, security
>
> To prepare for MESOS-4902, the Mesos master and agent need a way to set the
> authentication realm of an endpoint that has already been installed. Since
> some endpoints (like {{/profiler/*}}) get installed in libprocess, the
> master/agent should be able to specify during initialization what
> authentication realm the libprocess-level endpoints will be authenticated
> under.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2154) Port CFS quota support to Docker Containerizer
[ https://issues.apache.org/jira/browse/MESOS-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15197115#comment-15197115 ] haosdent commented on MESOS-2154: - I could rebase if you need. > Port CFS quota support to Docker Containerizer > -- > > Key: MESOS-2154 > URL: https://issues.apache.org/jira/browse/MESOS-2154 > Project: Mesos > Issue Type: Improvement > Components: docker, isolation >Affects Versions: 0.21.0 > Environment: Linux (Ubuntu 14.04.1) >Reporter: Andrew Ortman >Assignee: haosdent >Priority: Minor > > Port the CFS quota support the Mesos Containerizer has to the Docker > Containerizer. Whenever the --cgroup_enable_cfs flag is set, the Docker > Containerizer should update the cfs_period_us and cfs_quota_us values to > allow hard CPU capping on the container. > Current workaround is to pass those values as LXC configuration parameters -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2154) Port CFS quota support to Docker Containerizer
[ https://issues.apache.org/jira/browse/MESOS-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15197094#comment-15197094 ] Ian Babrou commented on MESOS-2154: --- Your patch is sitting around for 8 month. Is there anything that prevents it from being merged apart from docker version check? > The issue with only setting the CFS quota on the command line is that the > quota can change over time as tasks add/leave the container. [~SteveNiemitz] can you explain in a bit more detail how this happens with docker containers? > Port CFS quota support to Docker Containerizer > -- > > Key: MESOS-2154 > URL: https://issues.apache.org/jira/browse/MESOS-2154 > Project: Mesos > Issue Type: Improvement > Components: docker, isolation >Affects Versions: 0.21.0 > Environment: Linux (Ubuntu 14.04.1) >Reporter: Andrew Ortman >Assignee: haosdent >Priority: Minor > > Port the CFS quota support the Mesos Containerizer has to the Docker > Containerizer. Whenever the --cgroup_enable_cfs flag is set, the Docker > Containerizer should update the cfs_period_us and cfs_quota_us values to > allow hard CPU capping on the container. > Current workaround is to pass those values as LXC configuration parameters -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4779) Strip query strings and fragments from fetcher urls.
[ https://issues.apache.org/jira/browse/MESOS-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Rukletsov updated MESOS-4779: --- Summary: Strip query strings and fragments from fetcher urls. (was: strip query strings and fragments from fetcher urls) > Strip query strings and fragments from fetcher urls. > > > Key: MESOS-4779 > URL: https://issues.apache.org/jira/browse/MESOS-4779 > Project: Mesos > Issue Type: Bug > Components: fetcher >Reporter: James Peach >Assignee: James Peach >Priority: Minor > > When the fetcher URL contains a query string or fragment, the fetcher is > unable to check the file extension. We should strip the query and fragment > when constructing the Fetcher basename, -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2154) Port CFS quota support to Docker Containerizer
[ https://issues.apache.org/jira/browse/MESOS-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15197080#comment-15197080 ] haosdent commented on MESOS-2154: - Yes, in my patch use it. But only available on >=1.7.0. [~SteveNiemitz]'s patch works on all versions. > Port CFS quota support to Docker Containerizer > -- > > Key: MESOS-2154 > URL: https://issues.apache.org/jira/browse/MESOS-2154 > Project: Mesos > Issue Type: Improvement > Components: docker, isolation >Affects Versions: 0.21.0 > Environment: Linux (Ubuntu 14.04.1) >Reporter: Andrew Ortman >Assignee: haosdent >Priority: Minor > > Port the CFS quota support the Mesos Containerizer has to the Docker > Containerizer. Whenever the --cgroup_enable_cfs flag is set, the Docker > Containerizer should update the cfs_period_us and cfs_quota_us values to > allow hard CPU capping on the container. > Current workaround is to pass those values as LXC configuration parameters -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-2154) Port CFS quota support to Docker Containerizer
[ https://issues.apache.org/jira/browse/MESOS-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15197072#comment-15197072 ] Ian Babrou commented on MESOS-2154: --- Any news on this one? Looks like docker supports CFS natively now: https://github.com/docker/docker/pull/12180 > Port CFS quota support to Docker Containerizer > -- > > Key: MESOS-2154 > URL: https://issues.apache.org/jira/browse/MESOS-2154 > Project: Mesos > Issue Type: Improvement > Components: docker, isolation >Affects Versions: 0.21.0 > Environment: Linux (Ubuntu 14.04.1) >Reporter: Andrew Ortman >Assignee: haosdent >Priority: Minor > > Port the CFS quota support the Mesos Containerizer has to the Docker > Containerizer. Whenever the --cgroup_enable_cfs flag is set, the Docker > Containerizer should update the cfs_period_us and cfs_quota_us values to > allow hard CPU capping on the container. > Current workaround is to pass those values as LXC configuration parameters -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-4923) Treat revocable resources as a separate pool when considering fairness
[
https://issues.apache.org/jira/browse/MESOS-4923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Klaus Ma updated MESOS-4923:
Component/s: allocation
> Treat revocable resources as a separate pool when considering fairness
> --
>
> Key: MESOS-4923
> URL: https://issues.apache.org/jira/browse/MESOS-4923
> Project: Mesos
> Issue Type: Bug
> Components: allocation
>Reporter: Guangya Liu
>Assignee: Klaus Ma
>
> The current logic of roleSorter is that when it do role sorter, the resources
> in it will include both regular resources and revocable resources, and this
> may not accurate for some cases, take the following case as an instance:
> 1) framework1 and framework2.
> 2) framework1 got 1 reserved cpu and 9 revocable cpu. cpu(r1):1;cpu(*){REV}:9
> 3) framework2 got 9 reserved cpus: cpu(r1):9
> When allocator allocate resources in next cycle, framework2 will be handled
> first as it has less SCALAR resources than framework1, but this may not be
> right for some cases as framework1 is using only 1 reserved resources and
> other resources are revocable which can be easily got evicted.
> A proposal here is treat revocable resources as a separate pool when
> considering fairness, this can be achieved by introducing a new sorter for
> revocable resources so as to distinguish the sorter for regular resources and
> revocable resources. To the built in allocator, the logic would be as this:
> 1) Quota Role Sorter
> 2) non-revocable Role Sorter
> 3) Revocable Role Sorter
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4053) MemoryPressureMesosTest tests fail on CentOS 6.6
[
https://issues.apache.org/jira/browse/MESOS-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15196968#comment-15196968
]
haosdent commented on MESOS-4053:
-
If this test failed because of
{code}
(cgroups::destroy(hierarchy, cgroup)).failure(): Failed to remove cgroup
'/sys/fs/cgroup/perf_event/mesos_test': Device or resource busy
{code}
It is not because of the error of this case. It is because of some test cases
like
{code}
CgroupsAnyHierarchyWithPerfEventTest.ROOT_CGROUPS_Perf
{code}
failed and the process still exists in cgroup so that the cgroup could not be
removed successfully. I have a patch maybe related to this which wait for the
process exited. https://reviews.apache.org/r/43284/
> MemoryPressureMesosTest tests fail on CentOS 6.6
>
>
> Key: MESOS-4053
> URL: https://issues.apache.org/jira/browse/MESOS-4053
> Project: Mesos
> Issue Type: Bug
> Environment: CentOS 6.6
>Reporter: Greg Mann
>Assignee: Benjamin Hindman
> Labels: mesosphere, test-failure
>
> {{MemoryPressureMesosTest.CGROUPS_ROOT_Statistics}} and
> {{MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery}} fail on CentOS 6.6. It
> seems that mounted cgroups are not properly cleaned up after previous tests,
> so multiple hierarchies are detected and thus an error is produced:
> {code}
> [ RUN ] MemoryPressureMesosTest.CGROUPS_ROOT_Statistics
> ../../src/tests/mesos.cpp:849: Failure
> Value of: _baseHierarchy.get()
> Actual: "/cgroup"
> Expected: baseHierarchy
> Which is: "/tmp/mesos_test_cgroup"
> -
> Multiple cgroups base hierarchies detected:
> '/tmp/mesos_test_cgroup'
> '/cgroup'
> Mesos does not support multiple cgroups base hierarchies.
> Please unmount the corresponding (or all) subsystems.
> -
> ../../src/tests/mesos.cpp:932: Failure
> (cgroups::destroy(hierarchy, cgroup)).failure(): Failed to remove cgroup
> '/tmp/mesos_test_cgroup/perf_event/mesos_test': Device or resource busy
> [ FAILED ] MemoryPressureMesosTest.CGROUPS_ROOT_Statistics (12 ms)
> [ RUN ] MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
> ../../src/tests/mesos.cpp:849: Failure
> Value of: _baseHierarchy.get()
> Actual: "/cgroup"
> Expected: baseHierarchy
> Which is: "/tmp/mesos_test_cgroup"
> -
> Multiple cgroups base hierarchies detected:
> '/tmp/mesos_test_cgroup'
> '/cgroup'
> Mesos does not support multiple cgroups base hierarchies.
> Please unmount the corresponding (or all) subsystems.
> -
> ../../src/tests/mesos.cpp:932: Failure
> (cgroups::destroy(hierarchy, cgroup)).failure(): Failed to remove cgroup
> '/tmp/mesos_test_cgroup/perf_event/mesos_test': Device or resource busy
> [ FAILED ] MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery (7 ms)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2281) Deprecate plain text Credential format.
[
https://issues.apache.org/jira/browse/MESOS-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15196958#comment-15196958
]
Adam B commented on MESOS-2281:
---
Yeah, thanks for the link (to the awesome palindrome RR#). I re-read my
discussion with BenH there and spoke to Greg about it today, and I'm down for
using JSON now, if just to be more explicit (aka verbose) about the formatting.
We originally added JSON because we thought we would have separate credentials
lists for http vs. frameworks, and we still never did that. I proposed an
alternative where you just use different plaintext files, which could still be
an option, but json is more explicit.
> Deprecate plain text Credential format.
> ---
>
> Key: MESOS-2281
> URL: https://issues.apache.org/jira/browse/MESOS-2281
> Project: Mesos
> Issue Type: Improvement
> Components: master, slave
>Affects Versions: 0.21.1
>Reporter: Cody Maloney
>Assignee: Jan Schlicht
> Labels: mesosphere, security, tech-debt
>
> Currently two formats of credentials are supported: JSON
> {code}
> "credentials": [
> {
> "principal": "sherman",
> "secret": "kitesurf"
> }
> {code}
> And a new line file:
> {code}
> principal1 secret1
> pricipal2 secret2
> {code}
> We should deprecate the new line format and remove support for the old format.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
