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 w
On 1 October 2014 17:25, Allen Wittenauer 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
>
> IMO the scripting work you've done is a good example -- personally I really
> appreciate the work and I think it should be merged into branch-2 to
> benefit mainstream users when it's appropriate. Merging the work into
> branch-2 and starting the discussion of 3.x release, should be independent
On Oct 1, 2014, at 6:19 PM, Haohui Mai wrote:
>
> bq. Are we declaring that UIs are defacto non-stable?
>
> UI has been declared non-stable explicitly.
... then game over.
Go forth and break it.
bq. Besides that obvious problem, how does one simulate HDFS browsing
(especially going through the web auth--which is the key part!) via JMX or
REST? Will it provide the guarantees that I know that users who are using
browsers are functional?
It can be tested in the same way that the UI is teste
> Webui equivalent data has been exposed as jmx http APIs for a long time
Not true. HDFS-5342 was allegedly committed to branch-2 less than a
year ago.
Besides that obvious problem, how does one simulate HDFS browsing
(especially going through the web auth--which is the key par
+1 for removing the old UI.
On Wed, Oct 1, 2014 at 4:05 PM, Suresh Srinivas
wrote:
> Webui equivalent data has been exposed as jmx http APIs for a long time (I
> think from 0.20 release, almost 4 years ago). We have made many jsp changes
> that we have made that should have broken these applicat
Webui equivalent data has been exposed as jmx http APIs for a long time (I
think from 0.20 release, almost 4 years ago). We have made many jsp changes
that we have made that should have broken these applications many times. I
believe this is a frivolous objection for a functionality that as a co
+1 on removing the old JSP UI. Thanks.
Tsz-Wo
On Wednesday, October 1, 2014 3:34 PM, Haohui Mai wrote:
>
>
>Hi,
>
>Thanks for the discussions. If there is no objection, I plan to merge the
>related jiras from trunk to branch-2 in the coming days.
>
>~Haohui
>
>On Wed, Oct 1, 2014 at 2:35 PM
OK, then consider this an official objection. Yes, people do have
workflows based upon scraping the Web UIs, especially workflows that simulate
what interfaces users actually use.
On Oct 1, 2014, at 3:34 PM, Haohui Mai wrote:
> Hi,
>
> Thanks for the discussions. If there is no obje
Hi,
Thanks for the discussions. If there is no objection, I plan to merge the
related jiras from trunk to branch-2 in the coming days.
~Haohui
On Wed, Oct 1, 2014 at 2:35 PM, Suresh Srinivas
wrote:
> Sorry for responding very late. I am +1 on removing the JSP UI in branch-2
> for the following
Sorry for responding very late. I am +1 on removing the JSP UI in branch-2
for the following reasons:
1. The new web UI added has all the functionality of JSP UI.
2. For folks who might have used web UI to scrape the HDFS status, we have
build a http JMX interface a long time ago.
Given we do not
On Sep 11, 2014, at 3:29 PM, Haohui Mai wrote:
> Though I myself have to take the blame of creating these divergences -- I
> wonder, is it acceptable to resolve these divergences, by committing these
> patches that remove JSP UI to branch-2?
...
>
> Thoughts?
a) We have thre
Hi all,
In HDFS, the code that relates to webhdfs and UIs has diverged quite a bit
between branch-2 and trunk. This complicates the processes of maintaining
webhdfs in several jiras (e.g., HDFS-5946)
Most of the divergences come from removing the JSP UI and the related clean
ups that are committe
14 matches
Mail list logo
