Add support for mesos bay type

Registered by hongbin on 2015-05-22

In the Vancouvor design summit, we decided to add support for mesos bay type, which was briefly described in here https://etherpad.openstack.org/p/liberty-magnum-topics .

Blueprint information

Status:
Complete
Approver:
Steven Dake
Priority:
High
Drafter:
hongbin
Direction:
Approved
Assignee:
hongbin
Definition:
Approved
Series goal:
Accepted for liberty
Implementation:
Implemented
Milestone target:
milestone icon liberty-2
Started by
hongbin on 2015-06-08
Completed by
hongbin on 2015-07-16

Related branches

Sprints

Whiteboard

Discussion of blueprint on ML Thread:
http://lists.openstack.org/pipermail/openstack-dev/2015-May/065096.html

--

I did a preliminary research on possible implementations. I think this BP can be implemented in two steps.
1. Develop a heat template for provisioning mesos cluster.
2. Implement a magnum conductor for managing the mesos cluster.

First, I want to emphasis that mesos is not a service (It looks like a library). Therefore, mesos doesn't have web API, and most users don't use mesos directly. Instead, they use a mesos framework that is on top of mesos. Therefore, a mesos bay needs to have a mesos framework pre-configured so that magnum can talk to the framework to manage the bay. There are several framework choices. Below is a list of frameworks that look like a fit (in my opinion). A exhaustive list of framework can be found here [1].

1. Marathon [2]
This is a framework controlled by a company (mesosphere [3]). It is open source through. It supports running app on clusters of docker containers. It is probably the most widely-used mesos framework for long-running application.

2. Aurora [4]
This is a framework governed by Apache Software Foundation. It looks very similar to Marathon, but maybe more advanced in nature. It has been used by Twitter at scale. Here [5] is a detailed comparison between Marathon and Aurora.

3. Kubernetes/Docker swarm
It looks the swarm-mesos is not ready yet. I cannot find any thing about that (besides several videos on Youtube). The kubernetes-mesos is there [6]. In theory, magnum should be able to deploy a mesos bay and talk to the bay through kubernetes API. An advantage is that we can reuse the kubernetes conductor. A disadvantage is that it is not a 'mesos' way to manage containers. Users from mesos community are probably more comfortable to manage containers through Marathon/Aurora.

[1] http://mesos.apache.org/documentation/latest/mesos-frameworks/
[2] https://github.com/mesosphere/marathon
[3] https://mesosphere.com/
[4] http://aurora.apache.org/
[5] http://stackoverflow.com/questions/28651922/marathon-vs-aurora-and-their-purposes
[6] https://github.com/mesosphere/kubernetes-mesos
--hongbin

As discussed in the last team meeting [7], the first step is to support provisioning a Mesos+Marathon bay. For hosting OS, we are going to support Ubuntu or CentOS first. CoreOS could be support in a separated template.
[7] - http://eavesdrop.openstack.org/meetings/containers/2015/containers.2015-06-02-22.00.log.html

Gerrit topic: https://review.openstack.org/#q,topic:bp/mesos-bay-type,n,z

Addressed by: https://review.openstack.org/189179
    Initial Heat template for Mesos

Addressed by: https://review.openstack.org/189180
    WIP: Elements for building Mesos image

Addressed by: https://review.openstack.org/191476
    Add template definition of Mesos bay

(hongbin) Right now, all the patches are landed and we should have a mesos bay with basis functionalities. The supported mesos framework is Marathon (we are open for additional frameworks support). I am going to mark this BP as implemented, but the work on mesos bay is definitely continuing. There are several BPs created for different enhancement of mesos support. You are welcome to create more if the features you want haven't been covered.

Enhancement blueprints:
* Mutiple master node: https://blueprints.launchpad.net/magnum/+spec/mesos-multi-master-node
* Mesos conductor: https://blueprints.launchpad.net/magnum/+spec/mesos-conductor

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.