Uploaded image for project: 'Marathon'
  1. Marathon
  2. MARATHON-3580

[Question] Marathon resources role behavior

    Details

    • Type: Task
    • Status: Resolved
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:

      Description

      I'm trying to understand marathon resource role behavior by experimenting with following config.
      slave1: set with default_role as "busybox"
      slave2: set with default_role as "ubuntu"
      master: marathon-0.13.0-1.0.440.el7.x86_64

      Test1:

      • Start marathon with default config(no explicitly set /etc/marathon/conf/mesos_role)
      • Add acceptedResourcesRoles to "busybox" for busybox.json to launch as app1
      • At the same time, run a "ubuntu" version as app2.
        by my understanding, app1 will go to slave1 and app2 will go to slave2, but both app1 and app2 will not run actually.

      Test2:

      • Start marathon with default config(set /etc/marathon/conf/mesos_role to busybox)
      • Add acceptedResourcesRoles to "busybox" for busybox.json to launch as app1
      • At the same time, run a "ubuntu" version as app2.
        app1 goes to slave1 eventually as expected, while app2 still not running;
        swtich mesos_role to "ubuntu" and restart marathon, app2 will go to slave2, whileas app1 will not running.

      Is above behavior by design or I'm mis-configured somewhere?
      My understanding is: marathon will not bound with any particular role, it will schedule application with defined role to the corresponding resources, but from the test it's opposite.

      thanks!

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              GitHub_fengyuleidian0615 Fan Du (Inactive)
              Team:
              Orchestration Team
              Watchers:
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: