hui
> >>
> >>
> >>
> >> On Tue, Oct 29, 2013 at 5:22 AM, Zheng, Kai
> wrote:
> >>
> >> > > having /JMX for monitoring integration and a /JSON end point for
> the UI
> >> > IMHO, this makes sense, especially for the long
, WebUI serves as end user
>> > interface. Both might share same functionality codes, but that does not
>> > validate we couple them together.
>> >
>> > Thanks & regards,
>> > Kai
>> >
>> > -Original Message-
>> > Fro
es sense, especially for the long term. JMX interface
> > > serves
> > > > as management console in admin perspective, WebUI serves as end user
> > > > interface. Both might share same functionality codes, but that does
> not
> > > > validate we couple them to
and a /JSON end point for the
> UI
> > > IMHO, this makes sense, especially for the long term. JMX interface
> > serves
> > > as management console in admin perspective, WebUI serves as end user
> > > interface. Both might share same functionality codes, but that does not
ut that does not
> > validate we couple them together.
> >
> > Thanks & regards,
> > Kai
> >
> > -Original Message-----
> > From: Alejandro Abdelnur [mailto:t...@cloudera.com]
> > Sent: Tuesday, October 29, 2013 8:14 AM
> > To: hdfs-dev@hadoop
validate we couple them together.
>
> Thanks & regards,
> Kai
>
> -Original Message-
> From: Alejandro Abdelnur [mailto:t...@cloudera.com]
> Sent: Tuesday, October 29, 2013 8:14 AM
> To: hdfs-dev@hadoop.apache.org
> Subject: Re: Replacing the JSP web UIs to HTML
not validate we couple
them together.
Thanks & regards,
Kai
-Original Message-
From: Alejandro Abdelnur [mailto:t...@cloudera.com]
Sent: Tuesday, October 29, 2013 8:14 AM
To: hdfs-dev@hadoop.apache.org
Subject: Re: Replacing the JSP web UIs to HTML 5 applications
Isn't using JMX to
So, if I understand correctly, we are using an HTTP based API to access JMX
data. The API isn't strictly designed to REST principals but does reflect
the management API and query parameters of JMX.
While unfortunate that we don't have a better REST based design for it, it
may not add enough value
Just to provide some data point to make the discussion concrete. Here is a
part of the dump of the JMX information:
curl "
http://localhost:50070/jmx?qry=Hadoop:service=NameNode,name=NameNodeInfo";
{
"beans" : [ {
"name" : "Hadoop:service=NameNode,name=NameNodeInfo",
"modelerType" : "o
I think it is important that we make provisions for all Ajax calls to be
able to go through gateway deployments like Knox with the cluster
firewalled off.
As I have commented on the Jira, any calls that are currently on the
serverside but are moving to the browser will need to either require
punchi
Neither of them will go through JMX.
The new Web UI implements hdfs browsing through WebHDFS.
The logs are available through the static servlets, which is exactly the
same as what we have today.
Thanks,
Haohui
On Mon, Oct 28, 2013 at 6:01 PM, Alejandro Abdelnur wrote:
> are you planning to ex
are you planning to expose things like hdfs browsing and nn/dn logs over jmx?
thx
Alejandro
(phone typing)
On Oct 28, 2013, at 17:48, Haohui Mai wrote:
> It seems more appealing to me that the UI should JMX directly, because:
>
> * We're support the JMX in the long term for other management s
It seems more appealing to me that the UI should JMX directly, because:
* We're support the JMX in the long term for other management software.
* The information provided by the JMX API will be mostly identical of the
JSON API. Today the Web UI covers most of the information provided by JMX.
The W
Isn't using JMX to expose JSON for the web UI misusing JMX?
I would think a more appropriate approach would be having /JMX for
monitoring integration and a /JSON end point for the UI data.
Thanks.
On Mon, Oct 28, 2013 at 4:58 PM, Haohui Mai wrote:
> Alejandro,
>
> If I understand correctly, t
Alejandro,
If I understand correctly, that is the exact approach that the new web UI
is taking. The new web UI takes the output from JMX and renders them as
HTML at the client side.
~Haohui
On Mon, Oct 28, 2013 at 4:18 PM, Alejandro Abdelnur wrote:
> Haohui,
>
> If you have NN and DNs producin
Haohui,
If you have NN and DNs producing JSON instead HTML, then you can build JS
based web UIs. Take for example Oozie, Oozie produces JSON, it has a built
in JS web ui that consumes JSON and Hue has built an external web UI that
also consumes JSON. In the case of Hue UI, Oozie didn't have to cha
Hi Alejandro,
Can you please elaborate on producing JSON? All information presented in
the new Web UIs directly comes from the JMX side.
I'm okay with leaving the current JSP right now, since both the old and the
new Web UI can happily coexist.
When do you think it is a good time to switch the d
Echo my comments on HDFS-5402:
bq. If we're going to remove the old web UI, I think the new web UI has
to have the same level of unit testing. We shouldn't go backwards in
terms of unit testing.
I take a look at TestNamenodeJspHelper / TestDatanodeJspHelper /
TestClusterJspHelper. It seems to me
Producing JSON would be great. Agree with Colin that we should leave for
now the current JSP based web ui.
thx
On Mon, Oct 28, 2013 at 11:16 AM, Colin McCabe wrote:
> This is a really interesting project, Haohui. I think it will make
> our web UI much nicer.
>
> I have a few concerns about rem
This is a really interesting project, Haohui. I think it will make
our web UI much nicer.
I have a few concerns about removing the old web UI, however:
* If we're going to remove the old web UI, I think the new web UI has
to have the same level of unit testing. We shouldn't go backwards in
term
Thanks for the reply, Luke. Here I just echo my response from the jira:
bq. this client-side js only approach, which is less secure than a
progressively enhanced hybrid approach used by YARN. The recent gmail
XSS fiasco highlights the issue.
I'm presenting an informal security analysis to compare
Echoing my comments on HDFS-3555:
I have concerns with this client-side js only approach, which is less
secure than a progressively enhanced hybrid approach used by YARN. The
recent gmail XSS fiasco highlights the issue. I also have concerns that we
commit these changes without matching unit tests
Hi all,
Jing Zhao and I recently have reimplemented the JSP-based web UIs in HTML 5
applications (HDFS-5333). Based on our prelimanary testing results we
believe thst the new web UIs of the namenodes and the datanode are ready
for everyday uses.
You're more than welcome to try it out on trunk by
23 matches
Mail list logo