Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reservations are totally broken #148

Open
erikdw opened this issue Jun 10, 2016 · 0 comments
Open

reservations are totally broken #148

erikdw opened this issue Jun 10, 2016 · 0 comments

Comments

@erikdw
Copy link
Collaborator

erikdw commented Jun 10, 2016

@dsKarthick noticed a logic flaw with the existing use of reservations in storm-mesos:

Problematic sequence of events

  1. say an executor/MesosSupervisor is launched using some reserved resources for a role, and say the role is called storm-mesos-foo.
  2. then later we try to launch another task (storm worker) onto the same host, and thus under the same executor. That subsequent task's ExecutorInfo must 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.
  3. 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:

  1. Recording the info into a durable storage medium (e.g., ZooKeeper)
  2. 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).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant