Hi Christos,
This is absolutely fantastic to see. The design you've proposed here is
somehing a few members of our team here have been discussing, and we were very
close to putting together a design doc to share with the community, it's great
you've done this!
Regarding the design, for us you've hit the nail on the head. If you mix this
with the ability to plug custom modules in that respond to hooks, Mesos can
seamlessly integrate with any service discovery system as desired. Our original
idea was to implement some protobufs like you've done here, but use our
external containeriser to achieve announcements. A little hacky though.
One thing I would say though, restricting the "levels" or "namespaces" for the
services would be far from preferable. By this I mean specifying named
parameters for "environment" and "location". Different infrastructures have
multiple levels of grouping, for example...
- /ec2/{eu-west}/{1}/{my-vpc}/{my-az/my-subnet}/{my-cluster}/{my-service}
- /{london}/{my-subnet}/{my-cluster}/{my-service}
Perhaps an ordered list of environment or location labels might allow users to
be more flexible?
Also, it strikes me that a lot of this information is actually quite localised
to the slave itself, and therefore the cluster. For example, you could probably
tag the slave with a good chunk of the default discovery properties
("ec2/{eu-west}/1/{my-vpc}/{my-az/my-subnet}/{my-cluster}") without the
framework having to provide them. This would be especially useful when running
slaves across multiple geographic locations or sites, where you want that
information to be exposed in the discovery system but not to the framework.
I think it'd be great for frameworks to be provided with as little information
as possible as that will help reduce the barrier for adding new frameworks to a
cluster.
Tom.
--
Tom Arnfeld
Developer // DueDil
(+44) 7525940046
25 Christopher Street, London, EC2A 2BS
On Sat, Nov 22, 2014 at 2:25 AM, Christos Kozyrakis
<chris...@mesosphere.io> wrote:
> Hi everybody,
> I have created MESOS-2150
> <https://issues.apache.org/jira/browse/MESOS-2150> about
> adding service discovery info to tasks and executors at Mesos. A proposed
> design doc is available here
> <https://docs.google.com/document/d/1tpnjfHsa5Joka23CqgGppqnK0jODcElBvTFUBBO-A38/edit?usp=sharing>.
> The motivation is the following:
> ------
> Mesos enables flexible deployment of tasks in a shared cluster. A task may
> run on any slave and even move between slaves based on resource
> availability, framework shares, slave failures, and other constraints. To
> make the most of this flexibility, we need an automatic way to discover
> where tasks are and how to connect to the services they provide. To address
> this need, a number of service discovery systems have been proposed, based
> on proxies, DNS, or consistent stores such as Zookeeper and etcd.
> Any service discovery system needs to draw information about currently
> running tasks, their location, and their configuration parameters (IP
> address, ports, etc). In a Mesos cluster with multiple frameworks, the only
> authoritative source of information about running tasks is the master
> itself. In order to automatically manage the service discovery system, the
> task information available in the master should include service discovery
> preferences and parameters.
> If service discovery information is not available in the Mesos master,
> Mesos users will likely have to build auxiliary systems that gather and
> serve this information. Keeping the information in such auxiliary systems
> consistent with the task information in the master will only cause
> complications in the long term. It is best to store service discovery
> information along with all the other task information in the Mesos master.
> ------
> Looking forward to your feedback,
> Christos
