Welcome, happy to help!  I will answer your questions directly, but it may
also make sense to have a higher-level discussion about your requirements
to possibly offer alternative approaches.

1. Would it possible to subscribe to state change for a given job/task and
> receive notifications?


Not today, but i'm very open to the idea.  I think there are some cool
things you could implement with this behavior.  A concern i often have,
though, is that consumers of this data cannot handle cases where an event
fails to be delivered (i.e. they want a replica of the scheduler's state).
At any rate, i'd love to offer this behavior!

2. Would it possible to set a Pending time-out for tasks that take too long
> to be Assigned?


Not currently.  You could implement this by polling the API and killing
tasks that took too long to schedule.  This would allow you to decide how
to react (if at all).

3. Would it possible to have Aurora handle tasks with no resource
> constraints?


No.  Both Aurora and Mesos require CPU and memory to be specified for
tasks.  A client of Aurora could choose defaults, but the real question is:
what behavior do you want from scheduling without accounting?


On Mon, Nov 23, 2015 at 5:34 PM, Riccardo Poggi <riccardo.po...@cern.ch>
wrote:

> Hello,
>
> In order to introduce Aurora into our distributed system we would like to
> have it slowly, and hopefully transparently, replace what is currently the
> process manger component. To do that it would have to programmatically
> interface with other parts of the system that are, at the moment, taking
> care of what it could be considered the "active" orchestration.
>
> I've tried Aurora and looked at the docs, but I'm still left with some
> open questions:
>
> 1. Would it possible to subscribe to state change for a given job/task and
> receive notifications?
>
> 2. Would it possible to set a Pending time-out for tasks that take too
> long to be Assigned?
>
> 3. Would it possible to have Aurora handle tasks with no resource
> constraints?
>
>
> Thanks,
>   Riccardo
>

Reply via email to