Skip to content
This repository has been archived by the owner on Feb 1, 2021. It is now read-only.

Integrate Mesos into Scheduler API #214

Closed
tnachen opened this issue Dec 31, 2014 · 10 comments
Closed

Integrate Mesos into Scheduler API #214

tnachen opened this issue Dec 31, 2014 · 10 comments
Assignees
Milestone

Comments

@tnachen
Copy link
Contributor

tnachen commented Dec 31, 2014

No description provided.

@vieux vieux self-assigned this Jan 3, 2015
@abronan
Copy link
Contributor

abronan commented Jan 3, 2015

Do we integrate with Mesos directly or through Marathon which already manages containers on top of Mesos? Seems to me that we could easily map Swarm label/constraints with Marathon constraints. Same about your comment on #197 with health checks, tracking, etc. Swarm can access the Marathon API or be notified with the scheduler API thus letting the underlying scheduler deal with health checking mechanisms.

I'm not too familiar with Mesos but it seems that we still need to create a lightweight framework to deal with constraints so that we accept or decline offers from the Mesos Master if those constraints are met or not.

@tnachen
Copy link
Contributor Author

tnachen commented Jan 3, 2015

It depends on what swarm is trying to cover and the information that it needs.

Ideally using Marathon will be the simplest approach although swarm will needs another dependency service.

Building a framework in swarm will be the most flexible approach, with the cost of building from scratch, which might not be too bad.

I am trying to avoid having two frameworks (marathon and another) that swarm runs on. It becomes a lot easier to fail and harder to reason since there are two states that needs to be in sync.

@abronan
Copy link
Contributor

abronan commented Jan 3, 2015

"Building a framework in swarm will be the most flexible approach"

I am trying to avoid having two frameworks (marathon and another) that swarm runs on. It becomes a lot easier to fail and harder to reason since there are two states that needs to be in sync.

👍 Agree

@vieux Is it possible to extract, adapt and merge core parts of VoltFramework into Swarm then? At least we could get some inspiration from this project after some work with the pluggable Scheduler API :-)

@tnachen
Copy link
Contributor Author

tnachen commented Jan 4, 2015

I don't think voltframework integrates with swarm?

@vieux
Copy link
Contributor

vieux commented Jan 4, 2015

I also agree that swarm being a framework itself would be the most flexible approach.

No volt doesn't integrate with swarm, but it's a very simple framework written in pure go so it might look like the "swarm framework" in the end.

@aluzzardi
Copy link
Contributor

Agreed as well.

@davelester
Copy link

Since multiple Mesos schedulers (including Marathon, Aurora, and Singularity) can now schedule Docker containers, would it be possible for Swarm to offer a simple integration point with those instead creating a new framework? It's unclear to me why you'd want to create a new framework for this when there are already several options.

@vieux
Copy link
Contributor

vieux commented Feb 4, 2015

Is there a way something generic ? To my knowledge, it's not possible, as they all have a different way to communicate (proprietary API / CLI)

Our plan was to do a Scheduler API + implement simple Swarm framework, after, is the Aurora team wants to build and support the Swarm's "aurora backend" that would be great.

@tnachen
Copy link
Contributor Author

tnachen commented Feb 4, 2015

Hi Dave, I think the current swarm architecture is easier to integrate via it's own framework than calling other mesos meta framework as it is growing its feature set assuming communication directly to docker daemons instead using d

@tnachen tnachen closed this as completed Feb 4, 2015
@tnachen tnachen reopened this Feb 4, 2015
@tnachen
Copy link
Contributor Author

tnachen commented Feb 4, 2015

(Oops fat fingered on my phone!)

Hi Dave, I think the current swarm architecture is easier to integrate via it's own framework than calling other mesos meta framework as it is growing its feature set assuming communication directly to docker daemons instead using docker containerizer.

IMO as swarm is changinv rapidly and being designed along the way, it's easier to write it's own framework for now to also only store state in one framework

@aluzzardi aluzzardi added the next label Feb 5, 2015
@vieux vieux added this to the 0.2.0 milestone Feb 12, 2015
@vieux vieux added current and removed next labels Mar 17, 2015
@aluzzardi aluzzardi removed the current label Mar 18, 2015
@vieux vieux modified the milestones: 0.3.0, 0.2.0 Apr 3, 2015
@vieux vieux closed this as completed May 29, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants