-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Integrate Mesos into Scheduler API #214
Comments
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. |
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. |
👍 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 :-) |
I don't think voltframework integrates with swarm? |
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. |
Agreed as well. |
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. |
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. |
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 |
(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 |
No description provided.
The text was updated successfully, but these errors were encountered: