[
https://issues.apache.org/jira/browse/HDFS-12034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elek, Marton updated HDFS-12034:
--------------------------------
Description:
This is the pair of the HDFS-12005 but it's about the web interface of the
Ozone KSM server. I created a seperated issue to collect the required
data/mxbean separated and handle the two web interface independent one by one.
Required data:
* TODO
was:
This is a propsal about how a web interface could be implemented for SCM (and
later for KSM) similar to the namenode ui.
1. JS framework
There are three big option here.
A.) One is to use a full featured web framework with all the webpack/npm
minify/uglify magic. Build time the webpack/npm scripts should be run and the
result will be added to the jar file.
B.) It could be simplified if the generated minified/uglified js files are
added to the project on commit time. It requires an additional step for every
new patch (to generate the new minified javascripts) but doesn't require
additional JS build tools during the build.
C.) The third option is to make it as simple as possible similar to the current
namenode ui which uses javascript but every dependency is commited (without JS
minify/uglify and other preprocessing).
I prefer to the third one as:
* I have seen a lot of problems during frequent builds od older tez-ui
versions (bower version mismatch, npm version mismatch, npm transitive
dependency problems, proxy problem with older versions). All they could be
fixed but requires additional JS/NPM magic/knowledge. Without additional npm
build step the hdfs projects build could be kept more simple.
* The complexity of the planned SCM/KSM ui (hopefully it will remain simple)
doesn't require more sophisticated model. (Eg. we don't need JS require as we
need only a few controllers)
* HDFS developers mostly backend developers and not JS developers
2. Frameworks
The big advantages of a more modern JS framework is the simplified programming
model (for example with two way databinding) I suggest to use a more modern
framework (not just jquery) which supports plain js (not just
ECMA2015/2016/typescript) and just include the required js files in the
projects (similar to the included bootstrap or as the existing namenode ui
works).
* React could be a good candidate but it requires more library as it's just a
ui framework, even the REST calls need separated library. It could be used with
plain javascript instead of JSX and classes but not straightforward, and it's
more verbose.
* Ember is used in yarnui2 but the main strength of the ember is the CLI
which couldn't be used for the simplified approach easily. I think ember is
best with the A.) option
* Angular 1 is a good candidate (but not so fancy). In case of angular 1 the
component based approach should be used (in that case later it could be easier
to migrate to angular 2 or react)
* The mainstream side of Angular 2 uses typescript, it could work with plain
JS but it could require additional knowledge, most of the tutorials and
documentation shows the typescript approach.
I suggest to use angular 1 or react. Maybe angular is easier to use as don't
need to emulate JSX with function calls, simple HTML templates could be used.
3. Backend
I would prefer the approach of the existing namenode ui where the backend is
just the jmx endpoint. To keep it as simple as possible I suggest to try to
avoid dedicated REST backend if possible. Later we can use REST api of SCM/KSM
if they will be implemented.
> Ozone: Web interface for KSM
> ----------------------------
>
> Key: HDFS-12034
> URL: https://issues.apache.org/jira/browse/HDFS-12034
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: ozone
> Affects Versions: HDFS-7240
> Reporter: Elek, Marton
> Assignee: Elek, Marton
>
> This is the pair of the HDFS-12005 but it's about the web interface of the
> Ozone KSM server. I created a seperated issue to collect the required
> data/mxbean separated and handle the two web interface independent one by one.
> Required data:
> * TODO
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
