hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Haohui Mai <h...@hortonworks.com>
Subject Re: [DISCUSS] Resolving the divergences for web-related code between branch-2 and trunk
Date Thu, 02 Oct 2014 17:39:15 GMT
bq. If it cost nothing, I'd be in favour, but if the ongoing maintenance is
high then I think that it has to be retired at some time. All that's
being argued
about is "when".

There are several types of costs associated with the JSP UIs. For
example, fixing
security issues (HDFS-4901), and fixing webhdfs issues twice due to the
divergences between trunk and branch-2. I have been one of the people
maintaining JSP UI and webhdfs since 2.2, personally I think it is nice to
get rid of the extra costs when it is appropriate.

I think this is the right time to retire the old UI to reduce the costs of
maintenance. The new UI has been around since 2.3 and it
has stabilized through several releases.

~Haohui

On Thu, Oct 2, 2014 at 10:01 AM, Steve Loughran <stevel@hortonworks.com>
wrote:

> On 1 October 2014 17:25, Allen Wittenauer <aw@altiscale.com> wrote:
> >
> >     This is also an interesting precedent: Are we declaring that UIs are
> defacto non-stable?  Does this mean we can break the output of, e.g., count
> or ls or whatever because they don't have stabilities associated with
> them?  What line is to be drawn here?  IMO, difficulty in moving code is
> NOT a sufficient reason to throw out the compatibility guarantees.  It is
> only an indicator that we as a community are taking too long getting out
> releases.
> >
> >         If we do this change, then it's pretty much open season on all
> of other UI-incompatible changes sitting in trunk (and there are a
> bunch….).  Are we really ready to open the floodgates?
>
>
>
>
> http://hadoop.apache.org/docs/r2.5.1/hadoop-project-dist/hadoop-common/Compatibility.html#Web_UI
>
> Web UI
> ======
> Web UI, particularly the content and layout of web pages, changes
> could potentially interfere with attempts to screen scrape the web
> pages for information.
>
> Policy
> =====
>
> Web pages are not meant to be scraped and hence incompatible changes
> to them are allowed at any time. Users are expected to use REST APIs
> to get any information.
>
>
> we're saying "REST is stable; UI flexible"
>
> w.r.t browser simulation; HtmlUnit even handles javascript in its
> inside-JUnit4 test runs, negotiated connections &c. It can assess
> basic functionality. Real browser testing can be done with Selenium
>
> the risk that AW is pointing out on the NN UI is that it has been
> around  and stable long enough that it predates webhdfs, and because
> of its JSP-free view, has been amenable to scraping. Some people
> probably are still using it. Does that mean we should keep it? If it
> cost nothing, I'd be in favour, but if the ongoing maintenance is high
> then I think that it has to be retired at some time. All that's being
> argued about is "when".
>
> (BTW, this pushes for a REST-first policy on all future web work. Do
> the stable API then make the human-friendly view a thin layer in front
> of it)
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message