Hi Itamar, Wow, thanks for bringing this up!
The intended behavior is for *launchTasks* to take a set of tasks to be launched on a *single *slave. This means that the multiple offers passed to *launchTasks* must be from the *same *slave. The Python documentation absolutely should state this explicitly as it does for acceptOffers <https://github.com/apache/mesos/blob/master/src/python/interface/src/mesos/interface/__init__.py#L204-L213> as well as C++ *launchTasks <https://github.com/apache/mesos/blob/2985ae05634038b70f974bbfed6b52fe47231418/include/mesos/scheduler.hpp#L226-L237>*. If you would create a review request for this that would be awesome! Now, if this *is* the intended behavior, it raises the question - why does > launchTasks() support a set of tasks? doesn't mesos already aggregate > resources from the same slave to a single offer? The primary use case of this feature is to allow frameworks to hold onto offers and use them in conjunction with other offers from the same slave later on. MPark. On 19 March 2015 at 14:28, Sharma Podila <spod...@netflix.com> wrote: > I will assume that you are not talking of the case that a task actually is > being launched on multiple salves, since a task can only be launched on one > slave with existing concepts. > > Yes, that call is for one or more tasks on a single slave. That call > (since 0.18, I believe) also takes multiple offers of the same slave, which > can happen due to tasks finishing at different times on the host. > > I have seen discussion on batching status updates/acks. But, not on > batching launching of tasks across multiple slaves. From a user > perspective, I'd imagine that this should be possible. It would be useful > for frameworks with high rate of task dispatching. > > I suspect (purely my opinion) that this model may have come up in the > beginning when most frameworks were scheduling one task at a time before > moving to the next pending task. My framework, for example, runs a > scheduling loop/iteration and comes up with schedules for multiple tasks > across one more slaves. I would find it useful as well to batch up task > launches across multiple hosts. > > That said, I haven't found the existing method to be limiting in > performance/latency for our needs at this time. > > > > On Thu, Mar 19, 2015 at 8:19 AM, Itamar Ostricher <ita...@yowza3d.com> > wrote: > >> Hi, >> >> According to the Python interface docstring >> <https://github.com/apache/mesos/blob/master/src/python/interface/src/mesos/interface/__init__.py#L184-L193>, >> launchTasks() may be called with a set of tasks. >> >> In our framework, we thought this is used to issue a single RPC for >> launching many tasks onto many offers (potentially from many slaves), as an >> optimization (e.g., less communication overhead). >> >> But, when running with multiple slaves, we saw that tasks are lost when >> they are assigned to different slaves with the same launchTasks() call. >> >> Reading the docstring of launchTasks carefully, I still couldn't figure >> out that this is the intended behavior, so I'm here to verify that. >> If that's by design, it should be stated clearly in the docstring (I'd be >> happy to provide a documentation pull request for this). >> >> Now, if this *is* the intended behavior, it raises the question - why >> does launchTasks() support a set of tasks? doesn't mesos already aggregate >> resources from the same slave to a single offer? >> >> Thanks, >> - Itamar. >> > >
