[jira] [Created] (MESOS-5619) Add task_num to mesos-executor
Klaus Ma created MESOS-5619:
---
Summary: Add task_num to mesos-executor
Key: MESOS-5619
URL: https://issues.apache.org/jira/browse/MESOS-5619
Project: Mesos
Issue Type: Bug
Components: cli
Reporter: Klaus Ma
Assignee: Klaus Ma
According to current code, {{mesos-executor}} will only launch one task. It's
better to add a parameter to special how many task to launch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5618) Added a metric indicating if replicated log for the registrar has recovered or not.
Jie Yu created MESOS-5618: - Summary: Added a metric indicating if replicated log for the registrar has recovered or not. Key: MESOS-5618 URL: https://issues.apache.org/jira/browse/MESOS-5618 Project: Mesos Issue Type: Improvement Components: replicated log Reporter: Jie Yu Assignee: Jie Yu Fix For: 1.0.0 This gives operator insight about the state of the replicated log for registrar. The operator needs to know when it is safe to move on to another master in the upgrade orchestration pipeline. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5615) When using command executor, the ExecutorInfo is useless for sandbox authorization
[
https://issues.apache.org/jira/browse/MESOS-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15332751#comment-15332751
]
Joerg Schad commented on MESOS-5615:
Refactored sandbox authorization logic to use ObjectAuthorizer.
https://reviews.apache.org/r/48764/
Added 'labels' and 'discovery' to generated 'ExecutorInfo'.
https://reviews.apache.org/r/48765/
> When using command executor, the ExecutorInfo is useless for sandbox
> authorization
> --
>
> Key: MESOS-5615
> URL: https://issues.apache.org/jira/browse/MESOS-5615
> Project: Mesos
> Issue Type: Bug
> Components: modules, security, slave
>Affects Versions: 1.0.0
>Reporter: Alexander Rojas
>Assignee: Joerg Schad
>Priority: Blocker
> Labels: authorization, mesosphere, modularization, security
> Fix For: 1.0.0
>
>
> The design for sandbox access authorization uses the {{ExecutorInfo}}
> associated with the task as the main authorization space and the
> {{FrameworkInfo}} as a secondary one. This allows module writes to use fields
> such a labels for authorization.
> When a task uses the _command executor_ it doesn't provide an
> {{ExecutorInfo}}, but the info object is generated automatically inside the
> agent. As such, information which could be used for authorization (e.g.
> labels) is not available for authorization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-5615) When using command executor, the ExecutorInfo is useless for sandbox authorization
[
https://issues.apache.org/jira/browse/MESOS-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15332735#comment-15332735
]
Till Toenshoff edited comment on MESOS-5615 at 6/15/16 10:23 PM:
-
This however has implications; the derived {{ExecutorInfo}} is not just used
for the authorizer once we do this metadata duplication in
{{Slave::getExecutorInfo}} .
Consider a framework author who needs to provide {{Label}} in a way that makes
it unique across all Info's he is providing - say he does provide labels for
{{TaskInfo}} and also for {{FrameworkInfo}}. This author may be rather
surprised to see that suddenly such formerly unique {{Label}} is becoming
duplicated and popping up for both, his tasks and the resulting executors when
scraping slave endpoints. Same goes for {{DiscoveryInfo}} as attached to the
original task.
We need to document this behaviour well to prevent false assumptions.
was (Author: tillt):
This however has implications; the derived {{ExecutorInfo}} is not just used
for the authorizer once we do this metadata duplication in
{{Slave::getExecutorInfo}} .
Consider a framework author who needs to provide {{Label}}s in a way that makes
them unique across all Info's he is providing - say he does provide labels for
{{TaskInfo}} and also for {{FrameworkInfo}}. This author may be rather
surprised to see that suddenly such formerly unique {{Label}} is becoming
duplicated and popping up for both, his tasks and the resulting executors when
scraping slave endpoints. Same goes for {{DiscoveryInfo}} as attached to the
original task.
We need to document this behaviour well to prevent false assumptions.
> When using command executor, the ExecutorInfo is useless for sandbox
> authorization
> --
>
> Key: MESOS-5615
> URL: https://issues.apache.org/jira/browse/MESOS-5615
> Project: Mesos
> Issue Type: Bug
> Components: modules, security, slave
>Affects Versions: 1.0.0
>Reporter: Alexander Rojas
>Assignee: Joerg Schad
>Priority: Blocker
> Labels: authorization, mesosphere, modularization, security
> Fix For: 1.0.0
>
>
> The design for sandbox access authorization uses the {{ExecutorInfo}}
> associated with the task as the main authorization space and the
> {{FrameworkInfo}} as a secondary one. This allows module writes to use fields
> such a labels for authorization.
> When a task uses the _command executor_ it doesn't provide an
> {{ExecutorInfo}}, but the info object is generated automatically inside the
> agent. As such, information which could be used for authorization (e.g.
> labels) is not available for authorization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-5615) When using command executor, the ExecutorInfo is useless for sandbox authorization
[
https://issues.apache.org/jira/browse/MESOS-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15332735#comment-15332735
]
Till Toenshoff commented on MESOS-5615:
---
This however has implications; the derived {{ExecutorInfo}} is not just used
for the authorizer once we do this metadata duplication in
{{Slave::getExecutorInfo}} .
Consider a framework author who needs to provide {{Label}}s in a way that makes
them unique across all Info's he is providing - say he does provide labels for
{{TaskInfo}} and also for {{FrameworkInfo}}. This author may be rather
surprised to see that suddenly such formerly unique {{Label}} is becoming
duplicated and popping up for both, his tasks and the resulting executors when
scraping slave endpoints. Same goes for {{DiscoveryInfo}} as attached to the
original task.
We need to document this behaviour well to prevent false assumptions.
> When using command executor, the ExecutorInfo is useless for sandbox
> authorization
> --
>
> Key: MESOS-5615
> URL: https://issues.apache.org/jira/browse/MESOS-5615
> Project: Mesos
> Issue Type: Bug
> Components: modules, security, slave
>Affects Versions: 1.0.0
>Reporter: Alexander Rojas
>Assignee: Joerg Schad
>Priority: Blocker
> Labels: authorization, mesosphere, modularization, security
> Fix For: 1.0.0
>
>
> The design for sandbox access authorization uses the {{ExecutorInfo}}
> associated with the task as the main authorization space and the
> {{FrameworkInfo}} as a secondary one. This allows module writes to use fields
> such a labels for authorization.
> When a task uses the _command executor_ it doesn't provide an
> {{ExecutorInfo}}, but the info object is generated automatically inside the
> agent. As such, information which could be used for authorization (e.g.
> labels) is not available for authorization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3740) LIBPROCESS_IP not passed to Docker containers
[
https://issues.apache.org/jira/browse/MESOS-3740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15332711#comment-15332711
]
Adam B commented on MESOS-3740:
---
FYI, Mesosphere DCOS ships with a patch that attempts to address this issue:
https://github.com/mesosphere/mesos/commit/b9c622b53b3ffcc27911fcdcefc37a52ebe33bdd
> LIBPROCESS_IP not passed to Docker containers
> -
>
> Key: MESOS-3740
> URL: https://issues.apache.org/jira/browse/MESOS-3740
> Project: Mesos
> Issue Type: Bug
> Components: containerization, docker
>Affects Versions: 0.25.0
> Environment: Mesos 0.24.1
>Reporter: Cody Maloney
> Labels: mesosphere
>
> Docker containers aren't currently passed all the same environment variables
> that Mesos Containerizer tasks are. See:
> https://github.com/apache/mesos/blob/master/src/slave/containerizer/containerizer.cpp#L254
> for all the environment variables explicitly set for mesos containers.
> While some of them don't necessarily make sense for docker containers, when
> the docker has inside of it a libprocess process (A mesos framework
> scheduler) and is using {{--net=host}} the task needs to have LIBPROCESS_IP
> set otherwise the same sort of problems that happen because of MESOS-3553 can
> happen (libprocess will try to guess the machine's IP address with likely bad
> results in a number of operating environment).
--
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 ] Kapil Arya updated MESOS-5456: -- Shepherd: Kapil Arya (was: Jie Yu) > 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: 1.0.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] [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 ] Kapil Arya updated MESOS-5452: -- Shepherd: Kapil Arya (was: Jie Yu) > 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: 1.0.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 ] Kapil Arya updated MESOS-5456: -- Fix Version/s: 1.0.0 > 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: 1.0.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] [Commented] (MESOS-5489) Implement GET_STATE Call in v1 master API.
[ https://issues.apache.org/jira/browse/MESOS-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15332595#comment-15332595 ] Vinod Kone commented on MESOS-5489: --- Go for it!. Thank you!! > Implement GET_STATE Call in v1 master API. > -- > > Key: MESOS-5489 > URL: https://issues.apache.org/jira/browse/MESOS-5489 > Project: Mesos > Issue Type: Task >Reporter: Vinod Kone >Assignee: Vinod Kone > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5489) Implement GET_STATE Call in v1 master API.
[ https://issues.apache.org/jira/browse/MESOS-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinod Kone updated MESOS-5489: -- Assignee: Zhitao Li (was: Vinod Kone) > Implement GET_STATE Call in v1 master API. > -- > > Key: MESOS-5489 > URL: https://issues.apache.org/jira/browse/MESOS-5489 > Project: Mesos > Issue Type: Task >Reporter: Vinod Kone >Assignee: Zhitao Li > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5576) Masters may drop the first message they send between masters after a network partition
[
https://issues.apache.org/jira/browse/MESOS-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15332562#comment-15332562
]
Joseph Wu commented on MESOS-5576:
--
Some cleanup while reviewing the associated log replica tests:
|| Review || Summary ||
| https://reviews.apache.org/r/48571/ | Initialization asserts |
| https://reviews.apache.org/r/48572/ | Whitespace |
| https://reviews.apache.org/r/48573/ | Added check for non-deprecated field |
| https://reviews.apache.org/r/48574/ | Tweak CoordinatorTest.Elect |
| https://reviews.apache.org/r/48753/ | Tweak RecoverTest.CatchupRetry |
| https://reviews.apache.org/r/48752/ | Test summary comments |
> Masters may drop the first message they send between masters after a network
> partition
> --
>
> Key: MESOS-5576
> URL: https://issues.apache.org/jira/browse/MESOS-5576
> Project: Mesos
> Issue Type: Bug
> Components: leader election, master, replicated log
>Affects Versions: 0.28.2
> Environment: Observed in an OpenStack environment where each master
> lives on a separate VM.
>Reporter: Joseph Wu
>Assignee: Joseph Wu
> Labels: mesosphere
>
> We observed the following situation in a cluster of five masters:
> || Time || Master 1 || Master 2 || Master 3 || Master 4 || Master 5 ||
> | 0 | Follower | Follower | Follower | Follower | Leader |
> | 1 | Follower | Follower | Follower | Follower || Partitioned from cluster
> by downing this VM's network ||
> | 2 || Elected Leader by ZK | Voting | Voting | Voting | Suicides due to lost
> leadership |
> | 3 | Performs consensus | Replies to leader | Replies to leader | Replies to
> leader | Still down |
> | 4 | Performs writing | Acks to leader | Acks to leader | Acks to leader |
> Still down |
> | 5 | Leader | Follower | Follower | Follower | Still down |
> | 6 | Leader | Follower | Follower | Follower | Comes back up |
> | 7 | Leader | Follower | Follower | Follower | Follower |
> | 8 || Partitioned in the same way as Master 5 | Follower | Follower |
> Follower | Follower |
> | 9 | Suicides due to lost leadership || Elected Leader by ZK | Follower |
> Follower | Follower |
> | 10 | Still down | Performs consensus | Replies to leader | Replies to
> leader || Doesn't get the message! ||
> | 11 | Still down | Performs writing | Acks to leader | Acks to leader ||
> Acks to leader ||
> | 12 | Still down | Leader | Follower | Follower | Follower |
> Master 2 sends a series of messages to the recently-restarted Master 5. The
> first message is dropped, but subsequent messages are not dropped.
> This appears to be due to a stale link between the masters. Before leader
> election, the replicated log actors create a network watcher, which adds
> links to masters that join the ZK group:
> https://github.com/apache/mesos/blob/7a23d0da817be4e8f68d96f524cecf802431033c/src/log/network.hpp#L157-L159
> This link does not appear to break (Master 2 -> 5) when Master 5 goes down,
> perhaps due to how the network partition was induced (in the hypervisor
> layer, rather than in the VM itself).
> When Master 2 tries to send an {{PromiseRequest}} to Master 5, we do not
> observe the [expected log
> message|https://github.com/apache/mesos/blob/7a23d0da817be4e8f68d96f524cecf802431033c/src/log/replica.cpp#L493-L494]
> Instead, we see a log line in Master 2:
> {code}
> process.cpp:2040] Failed to shutdown socket with fd 27: Transport endpoint is
> not connected
> {code}
> The broken link is removed by the libprocess {{socket_manager}} and the
> following {{WriteRequest}} from Master 2 to Master 5 succeeds via a new
> socket.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (MESOS-5615) When using command executor, the ExecutorInfo is useless for sandbox authorization
[
https://issues.apache.org/jira/browse/MESOS-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Schad reassigned MESOS-5615:
--
Assignee: Joerg Schad (was: Alexander Rojas)
> When using command executor, the ExecutorInfo is useless for sandbox
> authorization
> --
>
> Key: MESOS-5615
> URL: https://issues.apache.org/jira/browse/MESOS-5615
> Project: Mesos
> Issue Type: Bug
> Components: modules, security, slave
>Affects Versions: 1.0.0
>Reporter: Alexander Rojas
>Assignee: Joerg Schad
>Priority: Blocker
> Labels: authorization, mesosphere, modularization, security
> Fix For: 1.0.0
>
>
> The design for sandbox access authorization uses the {{ExecutorInfo}}
> associated with the task as the main authorization space and the
> {{FrameworkInfo}} as a secondary one. This allows module writes to use fields
> such a labels for authorization.
> When a task uses the _command executor_ it doesn't provide an
> {{ExecutorInfo}}, but the info object is generated automatically inside the
> agent. As such, information which could be used for authorization (e.g.
> labels) is not available for authorization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (MESOS-5489) Implement GET_STATE Call in v1 master API.
[ https://issues.apache.org/jira/browse/MESOS-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15332522#comment-15332522 ] Zhitao Li edited comment on MESOS-5489 at 6/15/16 8:56 PM: --- [~vi...@twitter.com], as side effect of initial snapshot for Subscribe, I've pretty much got this done. If you don't mind, can you assign it to me and change to reviewable? Thanks. was (Author: zhitao): [~vi...@twitter.com], as side effect of initial snapshot for Subscribe, I've pretty much got this done. I'll claim this ticket and mark it as reviewable, if you don't mind :) > Implement GET_STATE Call in v1 master API. > -- > > Key: MESOS-5489 > URL: https://issues.apache.org/jira/browse/MESOS-5489 > Project: Mesos > Issue Type: Task >Reporter: Vinod Kone >Assignee: Vinod Kone > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5489) Implement GET_STATE Call in v1 master API.
[ https://issues.apache.org/jira/browse/MESOS-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15332522#comment-15332522 ] Zhitao Li commented on MESOS-5489: -- [~vi...@twitter.com], as side effect of initial snapshot for Subscribe, I've pretty much got this done. I'll claim this ticket and mark it as reviewable, if you don't mind :) > Implement GET_STATE Call in v1 master API. > -- > > Key: MESOS-5489 > URL: https://issues.apache.org/jira/browse/MESOS-5489 > Project: Mesos > Issue Type: Task >Reporter: Vinod Kone >Assignee: Vinod Kone > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-5615) When using command executor, the ExecutorInfo is useless for sandbox authorization
[
https://issues.apache.org/jira/browse/MESOS-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15332377#comment-15332377
]
Till Toenshoff commented on MESOS-5615:
---
After a quick discussion among [~vinodkone], [~js84] and [~jvanremoortere] we
decided to go with:
- copy all labels and similar metadata from {{TaskInfo}} into the derived
{{ExecutorInfo}}.
> When using command executor, the ExecutorInfo is useless for sandbox
> authorization
> --
>
> Key: MESOS-5615
> URL: https://issues.apache.org/jira/browse/MESOS-5615
> Project: Mesos
> Issue Type: Bug
> Components: modules, security, slave
>Affects Versions: 1.0.0
>Reporter: Alexander Rojas
>Assignee: Alexander Rojas
>Priority: Blocker
> Labels: authorization, mesosphere, modularization, security
> Fix For: 1.0.0
>
>
> The design for sandbox access authorization uses the {{ExecutorInfo}}
> associated with the task as the main authorization space and the
> {{FrameworkInfo}} as a secondary one. This allows module writes to use fields
> such a labels for authorization.
> When a task uses the _command executor_ it doesn't provide an
> {{ExecutorInfo}}, but the info object is generated automatically inside the
> agent. As such, information which could be used for authorization (e.g.
> labels) is not available for authorization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-2102) Allow configuration of external hostname for web ui
[ https://issues.apache.org/jira/browse/MESOS-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15332367#comment-15332367 ] Vinod Kone commented on MESOS-2102: --- Don't think anyone is working on it. It would be in "In Progress" or "Reviewable" state if so. More importantly, it's not clear how to solve this yet. > Allow configuration of external hostname for web ui > --- > > Key: MESOS-2102 > URL: https://issues.apache.org/jira/browse/MESOS-2102 > Project: Mesos > Issue Type: Improvement > Components: webui >Affects Versions: 0.20.1 >Reporter: Lukas Loesche > Labels: mesosphere > > You often have Mesos running in an environment where nodes have internal and > external IP addresses. > It would be advantageous for Mesos and Frameworks to do communication using > the internal IPs while users of the web ui connect to the external IPs. > At the moment if I set --hostname to the internal hostname that hostname is > propagated to the web ui and users can't open the slave sandbox. Also the > redirect to the active master leads to the wrong hostname then. > If I set --hostname to the external hostname I have to allow Mesos nodes to > communicate with each other using the public IP. > The way to work around this at the moment is to configure split DNS or > /etc/hosts entries. > It would be nice if I could define something like --webui-hostname or > --public-hostname so that nodes communicate via the private interfaces. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-5615) When using command executor, the ExecutorInfo is useless for sandbox authorization
[
https://issues.apache.org/jira/browse/MESOS-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff updated MESOS-5615:
--
Fix Version/s: 1.0.0
> When using command executor, the ExecutorInfo is useless for sandbox
> authorization
> --
>
> Key: MESOS-5615
> URL: https://issues.apache.org/jira/browse/MESOS-5615
> Project: Mesos
> Issue Type: Bug
> Components: modules, security, slave
>Affects Versions: 1.0.0
>Reporter: Alexander Rojas
>Assignee: Alexander Rojas
>Priority: Blocker
> Labels: authorization, mesosphere, modularization, security
> Fix For: 1.0.0
>
>
> The design for sandbox access authorization uses the {{ExecutorInfo}}
> associated with the task as the main authorization space and the
> {{FrameworkInfo}} as a secondary one. This allows module writes to use fields
> such a labels for authorization.
> When a task uses the _command executor_ it doesn't provide an
> {{ExecutorInfo}}, but the info object is generated automatically inside the
> agent. As such, information which could be used for authorization (e.g.
> labels) is not available for authorization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5617) Mesos website preview incorrect in facebook
haosdent created MESOS-5617: --- Summary: Mesos website preview incorrect in facebook Key: MESOS-5617 URL: https://issues.apache.org/jira/browse/MESOS-5617 Project: Mesos Issue Type: Improvement Components: project website Reporter: haosdent Assignee: haosdent Priority: Minor We need follow https://developers.facebook.com/docs/sharing/best-practices#images to avoid the preview logo of the sharing relateds to Mesos website be cropped by facebook. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-5616) Add missing comments for GET_FLAGS, GET_HEALTH, GET_VERSION, GET_LOGGING_LEVEL, GET_LEADING_MASTER
haosdent created MESOS-5616: --- Summary: Add missing comments for GET_FLAGS, GET_HEALTH, GET_VERSION, GET_LOGGING_LEVEL, GET_LEADING_MASTER Key: MESOS-5616 URL: https://issues.apache.org/jira/browse/MESOS-5616 Project: Mesos Issue Type: Bug Reporter: haosdent Assignee: haosdent Priority: Minor We need add missing comments for below operator APIs we implemented. * GET_FLAGS * GET_HEALTH * GET_VERSION * GET_LOGGING_LEVEL * GET_LEADING_MASTER -- 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=15332132#comment-15332132 ] haosdent commented on MESOS-4791: - [~vinodkone] Thank you for your remind. I found we miss this in those API submitted before. Let me create a ticket to track add them as well. > 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] [Comment Edited] (MESOS-5486) Implement SET_LOGGING_LEVEL Call in v1 master API.
[ https://issues.apache.org/jira/browse/MESOS-5486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326345#comment-15326345 ] haosdent edited comment on MESOS-5486 at 6/15/16 5:15 PM: -- | Exposed the logging process `PID` in libprocess. | https://reviews.apache.org/r/48595/ | | Added comments for `Call::SET_LOGGING_LEVEL`. | https://reviews.apache.org/r/48737/ | | Implemented v1::master::Call::SET_LOGGING_LEVEL. | https://reviews.apache.org/r/48596/ | was (Author: haosd...@gmail.com): | Exposed the logging process `PID` in libprocess. | https://reviews.apache.org/r/48595/ | | Implemented v1::master::Call::SET_LOGGING_LEVEL. | https://reviews.apache.org/r/48596/ | > Implement SET_LOGGING_LEVEL Call in v1 master API. > -- > > Key: MESOS-5486 > URL: https://issues.apache.org/jira/browse/MESOS-5486 > Project: Mesos > Issue Type: Task >Reporter: Vinod Kone >Assignee: haosdent > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MESOS-2533) Support HTTP checks in Mesos health check program
[ https://issues.apache.org/jira/browse/MESOS-2533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Rukletsov updated MESOS-2533: --- Story Points: 8 > Support HTTP checks in Mesos health check program > - > > Key: MESOS-2533 > URL: https://issues.apache.org/jira/browse/MESOS-2533 > Project: Mesos > Issue Type: Improvement >Reporter: Niklas Quarfot Nielsen >Assignee: haosdent > Labels: health-check, mesosphere > > Currently, only commands are supported but our health check protobuf enables > users to encode HTTP checks as well. We should wire up this in the health > check program or remove the http field from the protobuf. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (MESOS-5615) When using command executor, the ExecutorInfo is useless for sandbox authorization
[
https://issues.apache.org/jira/browse/MESOS-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Rojas reassigned MESOS-5615:
--
Assignee: Alexander Rojas
> When using command executor, the ExecutorInfo is useless for sandbox
> authorization
> --
>
> Key: MESOS-5615
> URL: https://issues.apache.org/jira/browse/MESOS-5615
> Project: Mesos
> Issue Type: Bug
> Components: modules, security, slave
>Affects Versions: 1.0.0
>Reporter: Alexander Rojas
>Assignee: Alexander Rojas
>Priority: Blocker
> Labels: authorization, mesosphere, modularization, security
>
> The design for sandbox access authorization uses the {{ExecutorInfo}}
> associated with the task as the main authorization space and the
> {{FrameworkInfo}} as a secondary one. This allows module writes to use fields
> such a labels for authorization.
> When a task uses the _command executor_ it doesn't provide an
> {{ExecutorInfo}}, but the info object is generated automatically inside the
> agent. As such, information which could be used for authorization (e.g.
> labels) is not available for authorization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5615) When using command executor, the ExecutorInfo is useless for sandbox authorization
[
https://issues.apache.org/jira/browse/MESOS-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff updated MESOS-5615:
--
Priority: Blocker (was: Major)
> When using command executor, the ExecutorInfo is useless for sandbox
> authorization
> --
>
> Key: MESOS-5615
> URL: https://issues.apache.org/jira/browse/MESOS-5615
> Project: Mesos
> Issue Type: Bug
> Components: modules, security, slave
>Affects Versions: 1.0.0
>Reporter: Alexander Rojas
>Priority: Blocker
> Labels: authorization, mesosphere, modularization, security
>
> The design for sandbox access authorization uses the {{ExecutorInfo}}
> associated with the task as the main authorization space and the
> {{FrameworkInfo}} as a secondary one. This allows module writes to use fields
> such a labels for authorization.
> When a task uses the _command executor_ it doesn't provide an
> {{ExecutorInfo}}, but the info object is generated automatically inside the
> agent. As such, information which could be used for authorization (e.g.
> labels) is not available for authorization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MESOS-5615) When using command executor, the ExecutorInfo is useless for sandbox authorization
[
https://issues.apache.org/jira/browse/MESOS-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Till Toenshoff updated MESOS-5615:
--
Affects Version/s: 1.0.0
> When using command executor, the ExecutorInfo is useless for sandbox
> authorization
> --
>
> Key: MESOS-5615
> URL: https://issues.apache.org/jira/browse/MESOS-5615
> Project: Mesos
> Issue Type: Bug
> Components: modules, security, slave
>Affects Versions: 1.0.0
>Reporter: Alexander Rojas
> Labels: authorization, mesosphere, modularization, security
>
> The design for sandbox access authorization uses the {{ExecutorInfo}}
> associated with the task as the main authorization space and the
> {{FrameworkInfo}} as a secondary one. This allows module writes to use fields
> such a labels for authorization.
> When a task uses the _command executor_ it doesn't provide an
> {{ExecutorInfo}}, but the info object is generated automatically inside the
> agent. As such, information which could be used for authorization (e.g.
> labels) is not available for authorization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5615) When using command executor, the ExecutorInfo is useless for sandbox authorization
Alexander Rojas created MESOS-5615:
--
Summary: When using command executor, the ExecutorInfo is useless
for sandbox authorization
Key: MESOS-5615
URL: https://issues.apache.org/jira/browse/MESOS-5615
Project: Mesos
Issue Type: Bug
Components: modules, security, slave
Reporter: Alexander Rojas
The design for sandbox access authorization uses the {{ExecutorInfo}}
associated with the task as the main authorization space and the
{{FrameworkInfo}} as a secondary one. This allows module writes to use fields
such a labels for authorization.
When a task uses the _command executor_ it doesn't provide an {{ExecutorInfo}},
but the info object is generated automatically inside the agent. As such,
information which could be used for authorization (e.g. labels) is not
available for authorization.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-5614) Documentation links to ".md" files don't work
Neil Conway created MESOS-5614:
--
Summary: Documentation links to ".md" files don't work
Key: MESOS-5614
URL: https://issues.apache.org/jira/browse/MESOS-5614
Project: Mesos
Issue Type: Bug
Components: documentation
Reporter: Neil Conway
Priority: Minor
A link like:
{noformat}
The [Docker Volume Driver
API](https://github.com/Docker/Docker/blob/master/docs/extend/plugins_volume.md)
{noformat}
Is turned into a link to
{{/documentation/latest/https://github.com/Docker/Docker/blob/master/docs/extend/plugins_volume.md}}
by the website generation script ({{site/Rakefile}}). The regexp in that
Rakefile obviously needs further tweaks. Of course, the right long-term fix is
to use a less fragile way to format the links.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
