• Type: Task
    • Status: Resolved
    • Priority: High
    • Resolution: Won't Do
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: API
    • Labels:


      The Marathon UI, DC/OS UI, and DC/OS CLI need to show App status, but they have to do some gymnastics to determine it because it's not in the API.

      We want the UI, CLI, and API to be consistent and fast. So we need Marathon itself to make the determination and put it in the API.

      Ideally the Pod and App statuses would be similar. That way the UI can keep showing them both on the same page as "Services" without complex mapping logic. In the future, it'd be nice if there actually was a single Service API, but that's out of scope for this issue.

      Right now, the Marathon UI has the following:

      • Running
      • Deploying
      • Suspended
      • Delayed
      • Waiting

      The Pods API has a PodState with the following states:

      • DEGRADED
      • STABLE
      • TERMINAL

      Delayed and Waiting are especially problematic to determine when listing Apps because you have to hit the Queue API too. Plus, the terms Delayed and Waiting are pretty non-intuitive. Both are error conditions that almost always require action, but the terms make it sound like waiting will resolve them.

      /cc [~james], Marco Monaco, Lee Munroe, Tobias Mueller, Matthias Eichstedt




            • Assignee:
              karl Karl Isenberg (Inactive)
              Orchestration Team
              Karl Isenberg (Inactive), Lee Munroe (Inactive), Matthias Eichstedt, Tim Harper, Tobias Mueller
            • Watchers:
              5 Start watching this issue


              • Created: