aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Suman Karumuri (JIRA)" <>
Subject [jira] [Updated] (AURORA-16) Refactor Aurora UI
Date Mon, 13 Jan 2014 19:10:51 GMT


Suman Karumuri updated AURORA-16:

    Labels: refactor_aurora_ui  (was: )

> Refactor Aurora UI
> ------------------
>                 Key: AURORA-16
>                 URL:
>             Project: Aurora
>          Issue Type: Epic
>          Components: UI, Usability
>            Reporter: Suman Karumuri
>            Assignee: Suman Karumuri
>              Labels: refactor_aurora_ui
> 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 core.
> 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.

This message was sent by Atlassian JIRA

View raw message