You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by Zhitao Li <zh...@gmail.com> on 2016/03/25 18:02:21 UTC
Event bus for Mesos
Hi,
Has anyone thought about the idea of building some kind of event bus
(similar to what Marathon provided) directly inside Mesos?
What I roughly have in mind:
1. The HTTP API effort already defined a very rich set of events, which
Mesos master/agent could send to scheduler/executor;
2. We could build an HTTP endpoint like `/v1/events`, which utilizes the
same mechanism of HTTP scheduler/executor API and allows a *subscriber* to
subscribe to event streams;
3. Some kind of filter rules as well as authorization is definitely
needed for both reducing traffic and enforce ACL.
Possible use cases I could image:
1. Pipe event streams to external database for analysis/archiving;
2. Faster notification to external service discovery systems like
Mesos-DNS w/o requiring it to poll /state from master;
3. Notification to other long running daemons for newly launched/killed
tasks at a Mesos agent
Please let me know what you think.
Thanks!
--
Cheers,
Zhitao Li
Re: Event bus for Mesos
Posted by Zhitao Li <zh...@gmail.com>.
Hi Ben,
Sorry for replying to this thread late. We are seriously planning for a
project which would utilize the DiscoveryInfo from Mesos master, and people
have already expressed concern about potential delay or frequency of how
fast we can poll this info from Mesos master.
I'll discuss more background and details in next work group.
On Fri, Mar 25, 2016 at 3:32 PM, Benjamin Mahler <bm...@apache.org> wrote:
> I think the consensus is that event streaming will come at some point.
>
> The status is that we opted to focus instead on making some significant
> performance improvements to the json endpoints and providing finer-grained
> endpoints, since these were a much simpler effort. The need at the time was
> primarily around the scalability of polling the endpoints: the master was
> blocking for an unacceptable amount of time for large clusters for the
> frequency of polling needed. One of the challenges with the event stream is
> that you don't have guarantees that mesos will send you every event (e.g.
> what if you disconnect for some time? what if there is a failure?). This
> also means you still have to rely on working off of snapshots.
>
> Also, if you have specific use cases, like lower mesos-dns latency, we
> could start with streaming support for DiscoveryInfo to limit the initial
> scope.
>
> On Fri, Mar 25, 2016 at 11:20 AM, Kevin Klues <kl...@gmail.com> wrote:
>
> > There is this design doc that was circulating a few months back, but
> > I'm not sure what the status of it is:
> >
> >
> >
> https://docs.google.com/document/d/1b2gheqWPw4V-60RdKu-dGWTy-qLGL5p5xJwmUXteDYE/edit?pli=1#heading=h.86u1r3w05n13
> >
> > On Fri, Mar 25, 2016 at 10:02 AM, Zhitao Li <zh...@gmail.com>
> wrote:
> > > Hi,
> > >
> > > Has anyone thought about the idea of building some kind of event bus
> > > (similar to what Marathon provided) directly inside Mesos?
> > >
> > > What I roughly have in mind:
> > >
> > > 1. The HTTP API effort already defined a very rich set of events,
> > which
> > > Mesos master/agent could send to scheduler/executor;
> > > 2. We could build an HTTP endpoint like `/v1/events`, which utilizes
> > the
> > > same mechanism of HTTP scheduler/executor API and allows a
> > *subscriber* to
> > > subscribe to event streams;
> > > 3. Some kind of filter rules as well as authorization is definitely
> > > needed for both reducing traffic and enforce ACL.
> > >
> > > Possible use cases I could image:
> > >
> > > 1. Pipe event streams to external database for analysis/archiving;
> > > 2. Faster notification to external service discovery systems like
> > > Mesos-DNS w/o requiring it to poll /state from master;
> > > 3. Notification to other long running daemons for newly
> > launched/killed
> > > tasks at a Mesos agent
> > >
> > > Please let me know what you think.
> > >
> > > Thanks!
> > >
> > > --
> > > Cheers,
> > >
> > > Zhitao Li
> >
> >
> >
> > --
> > ~Kevin
> >
>
--
Cheers,
Zhitao Li
Re: Event bus for Mesos
Posted by Benjamin Mahler <bm...@apache.org>.
I think the consensus is that event streaming will come at some point.
The status is that we opted to focus instead on making some significant
performance improvements to the json endpoints and providing finer-grained
endpoints, since these were a much simpler effort. The need at the time was
primarily around the scalability of polling the endpoints: the master was
blocking for an unacceptable amount of time for large clusters for the
frequency of polling needed. One of the challenges with the event stream is
that you don't have guarantees that mesos will send you every event (e.g.
what if you disconnect for some time? what if there is a failure?). This
also means you still have to rely on working off of snapshots.
Also, if you have specific use cases, like lower mesos-dns latency, we
could start with streaming support for DiscoveryInfo to limit the initial
scope.
On Fri, Mar 25, 2016 at 11:20 AM, Kevin Klues <kl...@gmail.com> wrote:
> There is this design doc that was circulating a few months back, but
> I'm not sure what the status of it is:
>
>
> https://docs.google.com/document/d/1b2gheqWPw4V-60RdKu-dGWTy-qLGL5p5xJwmUXteDYE/edit?pli=1#heading=h.86u1r3w05n13
>
> On Fri, Mar 25, 2016 at 10:02 AM, Zhitao Li <zh...@gmail.com> wrote:
> > Hi,
> >
> > Has anyone thought about the idea of building some kind of event bus
> > (similar to what Marathon provided) directly inside Mesos?
> >
> > What I roughly have in mind:
> >
> > 1. The HTTP API effort already defined a very rich set of events,
> which
> > Mesos master/agent could send to scheduler/executor;
> > 2. We could build an HTTP endpoint like `/v1/events`, which utilizes
> the
> > same mechanism of HTTP scheduler/executor API and allows a
> *subscriber* to
> > subscribe to event streams;
> > 3. Some kind of filter rules as well as authorization is definitely
> > needed for both reducing traffic and enforce ACL.
> >
> > Possible use cases I could image:
> >
> > 1. Pipe event streams to external database for analysis/archiving;
> > 2. Faster notification to external service discovery systems like
> > Mesos-DNS w/o requiring it to poll /state from master;
> > 3. Notification to other long running daemons for newly
> launched/killed
> > tasks at a Mesos agent
> >
> > Please let me know what you think.
> >
> > Thanks!
> >
> > --
> > Cheers,
> >
> > Zhitao Li
>
>
>
> --
> ~Kevin
>
Re: Event bus for Mesos
Posted by Kevin Klues <kl...@gmail.com>.
There is this design doc that was circulating a few months back, but
I'm not sure what the status of it is:
https://docs.google.com/document/d/1b2gheqWPw4V-60RdKu-dGWTy-qLGL5p5xJwmUXteDYE/edit?pli=1#heading=h.86u1r3w05n13
On Fri, Mar 25, 2016 at 10:02 AM, Zhitao Li <zh...@gmail.com> wrote:
> Hi,
>
> Has anyone thought about the idea of building some kind of event bus
> (similar to what Marathon provided) directly inside Mesos?
>
> What I roughly have in mind:
>
> 1. The HTTP API effort already defined a very rich set of events, which
> Mesos master/agent could send to scheduler/executor;
> 2. We could build an HTTP endpoint like `/v1/events`, which utilizes the
> same mechanism of HTTP scheduler/executor API and allows a *subscriber* to
> subscribe to event streams;
> 3. Some kind of filter rules as well as authorization is definitely
> needed for both reducing traffic and enforce ACL.
>
> Possible use cases I could image:
>
> 1. Pipe event streams to external database for analysis/archiving;
> 2. Faster notification to external service discovery systems like
> Mesos-DNS w/o requiring it to poll /state from master;
> 3. Notification to other long running daemons for newly launched/killed
> tasks at a Mesos agent
>
> Please let me know what you think.
>
> Thanks!
>
> --
> Cheers,
>
> Zhitao Li
--
~Kevin