[
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)
