[steveb]

Why you should care about this project: You wouldn't spend months building your own Linux distribution, so why spend time reinventing the wheel with chef/puppet/ansible?

We're not building a PaaS. Like a Linux distribution, we're integrating open source building blocks (logging, service discovery, scheduling) so that you can focus on app development and analytics instead of sysadmin tasks.

I'll be giving a talk to the NYC Mesos user group this Wednesday June 17th: http://www.meetup.com/Apache-Mesos-NYC-Meetup/events/2229328...

[x0rg]

I would really love to know more as I'm investing quite a bit of my time on this stuff.. I'll not be in NYC (unfortunately), could you please share you're slide then? Or maybe having a chat?

[wmf]

"When Mesos Met Consul" is a great topic for a talk, because I don't understand why you'd use both. Doesn't Mesos/Marathon remember what jobs it is running and where?

[steveb]

tl;dr: mesos/marathon run the tasks, consul exposes the tasks in DNS.

Both Mesos and Marathon store different views of task state on the cluster.

How do we use this data to make it easy for jobs to find one another? Can we use this information to automatically configure things like Load balancers?

This is where tools like consul and mesos-dns come in. They populate a DNS store, so that task-name becomes something like task-name.example.com. If you are running 10 copies of a service across different hosts, DNS will have 10 entries.

If a container moves to another system, DNS is updated on the fly.

We can embed health checks with consul, so that if a service is unhealthy, it gets pulled out of DNS.

Consul also is nice because the edges perform the checks (instead of a central server), so the load is distributed.