aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Suman Karumuri (JIRA)" <>
Subject [jira] [Created] (AURORA-16) Refactor Aurora UI
Date Thu, 02 Jan 2014 22:05:52 GMT
Suman Karumuri created AURORA-16:

             Summary: Refactor Aurora UI
                 Key: AURORA-16
             Project: Aurora
          Issue Type: New Feature
          Components: UI, Usability
            Reporter: Suman Karumuri
            Assignee: Suman Karumuri

Mostly copy-paste for posterity below:

Right now the UI is implemented directly within the aurora scheduler process. This has lead
to a proliferation of UI-only features and enhanced brittleness including:

1) Reliability - deadlock in the UI code can much more easily deadlock the scheduler.
2) Maintainability - features exist that are available in the UI but not via thrift (and thus
not available to the client, see JSON endpoints at /quotas, /slaves, /maintenance), or available
via thrift but not via the UI (see listBackups). Often these features need to be implemented
twice, once for thrift and once for the web UI, leading to more code paths into the scheduler
3) Usability - scheduler deploys take out the UI while storage reloads. With a separate UI
process we can return nice error messages instead and cut down on user confusion and panic.
4) Scalability - Building an abstraction for listeners to consume the checkpoint stream is
a valuable path to go down.  It would allow us to offload logic (such as UI or more expensive
computations such as scheduling risk analysis or admission control) to external processes
should the scheduling thread ever become a bottleneck.

Considering this, extract a separate and improved Aurora UI component that consumes data from
the Aurora core using only a thin API tbd.

\[See also MESOS-4732 for continued work on this project\]

This message was sent by Atlassian JIRA

View raw message