mesos-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Azul (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MESOS-2717) Qemu/KVM containerizer
Date Mon, 11 Apr 2016 10:46:25 GMT

    [ https://issues.apache.org/jira/browse/MESOS-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15234858#comment-15234858
] 

Azul commented on MESOS-2717:
-----------------------------

I have been following this JIRA, as I have a usage case where I could have used the KVM containerizer.

I use Mesos for CI through Jenkins and the Jenkins Mesos plugin, I had a couple of particular
needs:
1) I needed to be able to test a vagrant box, for that I needed not just virtualbox but I
needed to execute the 'vagrant up' command. This restricted me to able to use a virtualized
platforms that supported nested virtualization and virtualbox (probably only ESX would apply
here), or go down the bare-metal path and use something like mesos and the jenkins mesos plugin
for this task.
2) I need to be able to spin up full fat VMs of different types and OSs to run CI tests on
them, these are scrapped after every build.

For point 2, I could actually use Openstack or any other virtualization platform, but I don't
want to pay the maintenance burden of having an openstack installation, or pay for a vmware
offering.
There are a few 'workarounds' one can do with the default containerizer in mesos, for example:
execute a 'qemu-kvm' command and spin up an instance in a jenkins mesos build and then use
that instance for the test. It will get scrapped if the job dies.
Another option is to use something like rancher-vm, within docker with access to /dev/kvm
to allow full KVM hosts.

My perfect CI UX would be able to spin up a KVM instance, run a shell script and bring it
down again. I can already do this in Mesos with docker but I need a full fat vm

Another building block I see and could use,  would be that using marathon and a KVM containerizer
I could then build Stacks, a set of VMs where I could run whatever I choose in them (including
openstack!)



> 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)

Mime
View raw message