[
https://issues.apache.org/jira/browse/MESOS-8534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373027#comment-16373027
]
ASF GitHub Bot commented on MESOS-8534:
---------------------------------------
Github user sagar8192 commented on the issue:
https://github.com/apache/mesos/pull/263
@jdef, @qianzhangxa: I have added some more information about the use case
to the [ticket](https://issues.apache.org/jira/browse/MESOS-8534). Please check
it out. We are planning to discuss this in today's containerization sync.
> Allow nested containers in TaskGroups to have separate network namespaces
> -------------------------------------------------------------------------
>
> Key: MESOS-8534
> URL: https://issues.apache.org/jira/browse/MESOS-8534
> Project: Mesos
> Issue Type: Task
> Components: containerization
> Reporter: Sagar Sadashiv Patwardhan
> Priority: Minor
> Labels: cni
>
> As per the discussion with [~jieyu] and [~avinash.mesos] , I am going to
> allow nested containers in TaskGroups to have separate namespaces. I am also
> going to retain the existing functionality, where nested containers can share
> namespaces with the parent/root container.
> *Use case:* At Yelp, we have this application called seagull that runs
> multiple tasks in parallel. It is mainly used for running tests that depend
> on other containerized internal microservices. It was developed before mesos
> had support for docker-executor. So, it uses a custom executor, which
> directly talks to docker daemon on the host and run a bunch of service
> containers along with the process where tests are executed. Resources for all
> these containers are not accounted for in mesos. Clean-up of these containers
> is also a headache. We have a tool called docker-reaper that automatically
> reaps the orphaned containers once the executor goes away. In addition to
> that, we also run a few cron jobs that clean-up any leftover containers.
> We are in the process of containerizing the process that runs the tests. We
> also want to delegate the responsibility of lifecycle management of docker
> containers to mesos and get rid of the custom executor. We looked at a few
> alternatives to do this and decided to go with pods because they provide
> all-or-nothing(atomicity) semantics that we need for our application. But, we
> cannot use pods directly because all the containers in a pod have the same
> network namespace. The service discovery mechanism requires all the
> containers to have separate IPs. All of our microservices bind to 8888
> container port, so we will have port collision unless we are giving separate
> namespaces to all the containers in a pod.
> *Proposal:* I am planning to allow nested containers to have separate
> namespaces. If NetworkInfo protobuf for nested containers is not empty, then
> we will assign separate mnt and network namespaces to the nested containers.
> Otherwise, they will share the network and mount namepsaces with the
> parent/root container.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
