You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aurora.apache.org by "Suman Karumuri (JIRA)" <ji...@apache.org> on 2014/01/02 23:13:50 UTC
[jira] [Updated] (AURORA-16) Refactor Aurora UI
[ https://issues.apache.org/jira/browse/AURORA-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Suman Karumuri updated AURORA-16:
---------------------------------
Description:
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.
was:
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.
\[See also MESOS-4732 for continued work on this project\]
> Refactor Aurora UI
> ------------------
>
> Key: AURORA-16
> URL: https://issues.apache.org/jira/browse/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 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)