[jira] [Commented] (MESOS-6419) The 'master/teardown' endpoint should support tearing down 'unregistered_frameworks'.
[ https://issues.apache.org/jira/browse/MESOS-6419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15782055#comment-15782055 ] Adam B commented on MESOS-6419: --- [~neilc], [~vinodkone], now that this has landed in master, let's add the commit log to the comments here and set the fixVersion = 1.2.0 Seems like too large of a change to "backport" to 1.1.1, so we could even resolve the ticket if we're all done. > The 'master/teardown' endpoint should support tearing down > 'unregistered_frameworks'. > - > > Key: MESOS-6419 > URL: https://issues.apache.org/jira/browse/MESOS-6419 > Project: Mesos > Issue Type: Bug > Components: master >Affects Versions: 0.26.2, 0.27.3, 0.28.2, 1.0.1 >Reporter: Gilbert Song >Assignee: Neil Conway >Priority: Critical > Labels: endpoint, master > > This issue is exposed from > [MESOS-6400](https://issues.apache.org/jira/browse/MESOS-6400). When a user > is trying to tear down an 'unregistered_framework' from the 'master/teardown' > endpoint, a bad request will be returned: `No framework found with specified > ID`. > Ideally, we should support tearing down an unregistered framework, since > those frameworks may occur due to network partition, then all the orphan > tasks still occupy the resources. It would be a nightmare if a user has to > wait until the unregistered framework to get those resources back. > This may be the initial implementation: > https://github.com/apache/mesos/commit/bb8375975e92ee722befb478ddc3b2541d1ccaa9 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6281) Document how executors can obtain the IP address of the container
[
https://issues.apache.org/jira/browse/MESOS-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15781461#comment-15781461
]
Avinash Sridharan commented on MESOS-6281:
--
[~anandmazumdar] you want to take this up?
> Document how executors can obtain the IP address of the container
> -
>
> Key: MESOS-6281
> URL: https://issues.apache.org/jira/browse/MESOS-6281
> Project: Mesos
> Issue Type: Improvement
>Reporter: Zameer Manji
>Assignee: Avinash Sridharan
>Priority: Minor
>
> From the discussion in #containerizer on Slack.
> Documentation would be nice on the best practice on how an executor can
> obtain the IP address of the container. Some options were discussed:
> * Should it check {{LIBPROCESS_IP}}?
> * Should it use {{getaddrinfo(3)}}?
> * Should {{NetworkInfo}} be exposed to the executor?
> A concrete use case of this would be for thermos (Aurora's executor). It
> needs to figure out an ip address to announce to ZK for discovery.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6281) Document how executors can obtain the IP address of the container
[
https://issues.apache.org/jira/browse/MESOS-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15781376#comment-15781376
]
Zameer Manji commented on MESOS-6281:
-
It is possible to use system calls. It is the second option listed in the
ticket.
This ticket is about documenting what the best practice is and what options can
be used by executors regardless of isolation. The chat in #containerizer
references some confusion on what an executor should do. IMHO, {{NetworkInfo}}
should be exposed to the executor, it is the simplest method and it should work
in all isolation cases.
In Aurora's case the framework doesn't consume the IP addresses for any reason,
the executor is simply publishing the IP address to ZK for discovery. Here we
are trying to determine the public IP address(es) of the task to advertise so
it can be discovered.
> Document how executors can obtain the IP address of the container
> -
>
> Key: MESOS-6281
> URL: https://issues.apache.org/jira/browse/MESOS-6281
> Project: Mesos
> Issue Type: Improvement
>Reporter: Zameer Manji
>Assignee: Avinash Sridharan
>Priority: Minor
>
> From the discussion in #containerizer on Slack.
> Documentation would be nice on the best practice on how an executor can
> obtain the IP address of the container. Some options were discussed:
> * Should it check {{LIBPROCESS_IP}}?
> * Should it use {{getaddrinfo(3)}}?
> * Should {{NetworkInfo}} be exposed to the executor?
> A concrete use case of this would be for thermos (Aurora's executor). It
> needs to figure out an ip address to announce to ZK for discovery.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6571) Add "--task" flag to mesos-execute
[
https://issues.apache.org/jira/browse/MESOS-6571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15781300#comment-15781300
]
Alexander Rukletsov commented on MESOS-6571:
Yes, either a "short" version of that file with only your functions or you have
to backport—partially or completely—the dependency as well. I left this to you
since I might lack some context and would have done the wrong decision. But at
a first glance it looked like you don't really use anything from that file, so
"short" version of the file (with a comment describing why it differs from the
master) sounds good.
> Add "--task" flag to mesos-execute
> --
>
> Key: MESOS-6571
> URL: https://issues.apache.org/jira/browse/MESOS-6571
> Project: Mesos
> Issue Type: Improvement
>Reporter: Qian Zhang
>Assignee: Qian Zhang
> Fix For: 1.2.0
>
>
> In [MESOS-6096 | https://issues.apache.org/jira/browse/MESOS-6096], we have
> added the flag {{\--task_group}} to {{mesos-execute}} such that user can
> specify a {{TaskGroupInfo}} json with that flag to launch a task group. In
> this ticket, we'd like to add another flag {{\--task}} for user to specify
> {{TaskInfo}} json to launch a task.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MESOS-6841) Allow Dynamic CNI Configuration
Miguel Bernadin created MESOS-6841:
--
Summary: Allow Dynamic CNI Configuration
Key: MESOS-6841
URL: https://issues.apache.org/jira/browse/MESOS-6841
Project: Mesos
Issue Type: Improvement
Components: agent
Reporter: Miguel Bernadin
Priority: Minor
Agents has the ability to set resources dynamically without agent restart.
After seeing that CNI is configured at agent startup we could add Dynamic CNI
Configuration support in the future. Creating this JIRA is to track this effort.
{quote}
Note that the network/cni isolator learns all the available networks by looking
at the CNI configuration in the --network_cni_config_dir at startup. This
implies that if a new CNI network needs to be added after Agent startup, the
Agent needs to be restarted. The network/cni isolator has been designed with
recover capabilities and hence restarting the Agent (and therefore the
network/cni isolator) will not affect container orchestration.
{quote}
Sourced from http://mesos.apache.org/documentation/latest/cni/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-6281) Document how executors can obtain the IP address of the container
[
https://issues.apache.org/jira/browse/MESOS-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15780750#comment-15780750
]
Avinash Sridharan commented on MESOS-6281:
--
[~StephanErb] if its a question of discovering all the non-local IP address
assigned to that network namespace why can't you rely on system calls to
discover all the IP addresses. Here is an example of how we do it in the
`libprocess` world:
https://github.com/apache/mesos/blob/master/src/tests/containerizer/cni_isolator_tests.cpp#L66-L76
Also, just curious to know, if you know all the IP addresses allocated to the
network namespace and announce to ZK, how would frameworks like AURORA figure
out which IP address to use?
> Document how executors can obtain the IP address of the container
> -
>
> Key: MESOS-6281
> URL: https://issues.apache.org/jira/browse/MESOS-6281
> Project: Mesos
> Issue Type: Improvement
>Reporter: Zameer Manji
>Assignee: Avinash Sridharan
>Priority: Minor
>
> From the discussion in #containerizer on Slack.
> Documentation would be nice on the best practice on how an executor can
> obtain the IP address of the container. Some options were discussed:
> * Should it check {{LIBPROCESS_IP}}?
> * Should it use {{getaddrinfo(3)}}?
> * Should {{NetworkInfo}} be exposed to the executor?
> A concrete use case of this would be for thermos (Aurora's executor). It
> needs to figure out an ip address to announce to ZK for discovery.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4641) Support Container Network Interface (CNI).
[ https://issues.apache.org/jira/browse/MESOS-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15780580#comment-15780580 ] Stephan Erb commented on MESOS-4641: CNI supports multiple IP addresses. From an executor standpoint this makes it difficult to discover the 'correct' one as the associated metadata is missing. > Support Container Network Interface (CNI). > -- > > Key: MESOS-4641 > URL: https://issues.apache.org/jira/browse/MESOS-4641 > Project: Mesos > Issue Type: Epic >Reporter: Jie Yu >Assignee: Qian Zhang >Priority: Critical > Labels: mesosphere > > CoreOS developed the Container Network Interface (CNI), a proposed standard > for configuring network interfaces for Linux containers. Many CNI plugins > (e.g., calico) have already been developed. > https://coreos.com/blog/rkt-cni-networking.html > https://github.com/appc/cni/blob/master/SPEC.md > Kubernetes supports CNI as well. > http://blog.kubernetes.io/2016/01/why-Kubernetes-doesnt-use-libnetwork.html > In the context of Unified Containerizer, it would be nice if we can have a > 'network/cni' isolator which will speak the CNI protocol and prepare the > network for the container. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4641) Support Container Network Interface (CNI).
[ https://issues.apache.org/jira/browse/MESOS-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15780547#comment-15780547 ] Qian Zhang commented on MESOS-4641: --- [~StephanErb], executor is running inside of container, so I think in your executor, you can use related system call to get the assign IP. > Support Container Network Interface (CNI). > -- > > Key: MESOS-4641 > URL: https://issues.apache.org/jira/browse/MESOS-4641 > Project: Mesos > Issue Type: Epic >Reporter: Jie Yu >Assignee: Qian Zhang >Priority: Critical > Labels: mesosphere > > CoreOS developed the Container Network Interface (CNI), a proposed standard > for configuring network interfaces for Linux containers. Many CNI plugins > (e.g., calico) have already been developed. > https://coreos.com/blog/rkt-cni-networking.html > https://github.com/appc/cni/blob/master/SPEC.md > Kubernetes supports CNI as well. > http://blog.kubernetes.io/2016/01/why-Kubernetes-doesnt-use-libnetwork.html > In the context of Unified Containerizer, it would be nice if we can have a > 'network/cni' isolator which will speak the CNI protocol and prepare the > network for the container. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-6839) It is currently impossible to kill a task in the Windows executor
[ https://issues.apache.org/jira/browse/MESOS-6839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15780444#comment-15780444 ] Till Toenshoff commented on MESOS-6839: --- Can you add a bit more context here -- e.g. what happens if you try to kill a task and or the reasoning, if available. I believe that way other users are more likely to find value in this ticket. > It is currently impossible to kill a task in the Windows executor > - > > Key: MESOS-6839 > URL: https://issues.apache.org/jira/browse/MESOS-6839 > Project: Mesos > Issue Type: Bug > Components: agent >Reporter: Alex Clemmer >Assignee: Alex Clemmer >Priority: Blocker > Labels: microsoft > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4641) Support Container Network Interface (CNI).
[ https://issues.apache.org/jira/browse/MESOS-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15780201#comment-15780201 ] Stephan Erb commented on MESOS-4641: I would currently see MESOS-6281 as a blocker as well. It kind of prevents us from tackling AURORA-1790 as we have no proper mechanism to discover the CNI-assigned IP addresses within a launched executor. > Support Container Network Interface (CNI). > -- > > Key: MESOS-4641 > URL: https://issues.apache.org/jira/browse/MESOS-4641 > Project: Mesos > Issue Type: Epic >Reporter: Jie Yu >Assignee: Qian Zhang >Priority: Critical > Labels: mesosphere > > CoreOS developed the Container Network Interface (CNI), a proposed standard > for configuring network interfaces for Linux containers. Many CNI plugins > (e.g., calico) have already been developed. > https://coreos.com/blog/rkt-cni-networking.html > https://github.com/appc/cni/blob/master/SPEC.md > Kubernetes supports CNI as well. > http://blog.kubernetes.io/2016/01/why-Kubernetes-doesnt-use-libnetwork.html > In the context of Unified Containerizer, it would be nice if we can have a > 'network/cni' isolator which will speak the CNI protocol and prepare the > network for the container. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MESOS-6840) Tests for quota capacity heuristic.
Alexander Rukletsov created MESOS-6840: -- Summary: Tests for quota capacity heuristic. Key: MESOS-6840 URL: https://issues.apache.org/jira/browse/MESOS-6840 Project: Mesos Issue Type: Task Components: test Reporter: Alexander Rukletsov Assignee: Zhitao Li We need more tests to ensure capacity heuristic works as expected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
