[
https://issues.apache.org/jira/browse/MESOS-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15233927#comment-15233927
]
Alex Glikson edited comment on MESOS-2717 at 4/10/16 6:45 AM:
--------------------------------------------------------------
Great initiative!
I have an idea which is likely to raise some eyebrows.
Given that lots of effort has been already invested in managing a cluster of
KVM/Qemu hypervisors, with OpenStack being a very notable one, why don't we
piggy-back on that, and have a 'framework' and a 'containerizer' that delegate
to OpenStack APIs? We actually have a prototype of this working (with some
limitations), and can share impressions/code if folks are interested.
Regards,
Alex
was (Author: glikson):
Great initiative!
I have an idea which is likely to raise some eyebrows.
Assuming that lots of effort has been already invested in managing a cluster of
KVM/Qemu hypervisors, with OpenStack being a very notable one, why don't we
piggy-back on that, and have a 'framework' and a 'containerizer' that delegate
to OpenStack APIs? We actually have a prototype of this working (with some
limitations), and can share impressions/code if folks are interested.
Regards,
Alex
> Qemu/KVM containerizer
> ----------------------
>
> Key: MESOS-2717
> URL: https://issues.apache.org/jira/browse/MESOS-2717
> Project: Mesos
> Issue Type: Wish
> Components: containerization
> Reporter: Pierre-Yves Ritschard
> Assignee: Abhishek Dasgupta
>
> I think it would make sense for Mesos to have the ability to treat
> hypervisors as containerizers and the most sensible one to start with would
> probably be Qemu/KVM.
> There are a few workloads that can require full-fledged VMs (the most obvious
> one being Windows workloads).
> The containerization code is well decoupled and seems simple enough, I can
> definitely take a shot at it. VMs do bring some questions with them here is
> my take on them:
> 1. Routing, network strategy
> ======================
> The simplest approach here might very well be to go for bridged networks
> and leave the setup and inter slave routing up to the administrator
> 2. IP Address assignment
> ====================
> At first, it can be up to the Frameworks to deal with IP assignment.
> The simplest way to address this could be to have an executor running
> on slaves providing the qemu/kvm containerizer which would instrument a DHCP
> server and collect IP + Mac address resources from slaves. While it may be up
> to the frameworks to provide this, an example should most likely be provided.
> 3. VM Templates
> ==============
> VM templates should probably leverage the fetcher and could thus be copied
> locally or fetch from HTTP(s) / HDFS.
> 4. Resource limiting
> ================
> Mapping resouce constraints to the qemu command line is probably the easiest
> part, Additional command line should also be fetchable. For Unix VMs, the
> sandbox could show the output of the serial console
> 5. Libvirt / plain Qemu
> =================
> I tend to favor limiting the amount of necessary hoops to jump through and
> would thus investigate working directly with Qemu, maintaining an open
> connection to the monitor to assert status.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
