[
https://issues.apache.org/jira/browse/AURORA-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jake Farrell updated AURORA-16:
-------------------------------
Labels: refactor (was: refactor_aurora_ui)
> Refactor Aurora UI
> ------------------
>
> Key: AURORA-16
> URL: https://issues.apache.org/jira/browse/AURORA-16
> Project: Aurora
> Issue Type: Epic
> Components: UI, Usability
> Reporter: Suman Karumuri
> Assignee: Suman Karumuri
> Labels: refactor
>
> 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
(v6.1.5#6160)
