You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@dsKarthick noticed a logic flaw with the existing use of reservations in storm-mesos:
Problematic sequence of events
say an executor/MesosSupervisor is launched using some reserved resources for a role, and say the role is called storm-mesos-foo.
then later we try to launch another task (storm worker) onto the same host, and thus under the same executor. That subsequent task's ExecutorInfomust match the previous task's ExecutorInfo, or the task will be rejected. And the previous task included the role of storm-mesos-foo in its ExecutorInfo.
To set the role appropriately, we need to have some knowledge that we don't have right now: which executors are running and what are their roles?
Possible solutions
Some ideas for having the information about existing executor->role mappings available when we schedule tasks in MesosNimbus:
Recording the info into a durable storage medium (e.g., ZooKeeper)
OR Just keeping the state in memory, and when MesosNimbus restarts we reconcile framework state with mesos to rebuild this saved information (reconcile Mesos state with MesosNimbus #159).
The text was updated successfully, but these errors were encountered:
@dsKarthick noticed a logic flaw with the existing use of reservations in storm-mesos:
Problematic sequence of events
storm-mesos-foo
.ExecutorInfo
must match the previous task'sExecutorInfo
, or the task will be rejected. And the previous task included the role ofstorm-mesos-foo
in itsExecutorInfo
.Possible solutions
Some ideas for having the information about existing executor->role mappings available when we schedule tasks in MesosNimbus:
The text was updated successfully, but these errors were encountered: