Details

    • Type: Sub-task Sub-task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      This JIRA tracks the discussion of transitioning from old, JSP web UIs to the HTML 5 based web UIs.

        Activity

        Hide
        Colin Patrick McCabe added a comment -

        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
          terms of unit testing.
        • Most of the deployments of elinks and links out there don't support
          Javascript. This is just a reality of life when using CentOS 5 or 6,
          which many users are still using. I have used "links" to diagnose
          problems through the web UI in the past, in systems where access to
          the cluster was available only through telnet. If we are going to
          remove this capability, we need to add some other command-line tools
          to get the same functionality. These tools could use REST if we have
          that, or JMX, but they need to exist before we can consider removing
          the old UI.
        Show
        Colin Patrick McCabe added a comment - 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 terms of unit testing. Most of the deployments of elinks and links out there don't support Javascript. This is just a reality of life when using CentOS 5 or 6, which many users are still using. I have used "links" to diagnose problems through the web UI in the past, in systems where access to the cluster was available only through telnet. If we are going to remove this capability, we need to add some other command-line tools to get the same functionality. These tools could use REST if we have that, or JMX, but they need to exist before we can consider removing the old UI.
        Hide
        Haohui Mai added a comment -

        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 that we can merge these tests with the unit tests on JMX.

        If we are going to

        remove this capability, we need to add some other command-line tools
        to get the same functionality. These tools could use REST if we have
        that, or JMX, but they need to exist before we can consider removing
        the old UI.

        This is a good point. Since all information are available through JMX, the easiest way to approach it is to write some scripts using Node.js. The architecture of the new Web UIs is ready for this.

        Show
        Haohui Mai added a comment - 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 that we can merge these tests with the unit tests on JMX. If we are going to remove this capability, we need to add some other command-line tools to get the same functionality. These tools could use REST if we have that, or JMX, but they need to exist before we can consider removing the old UI. This is a good point. Since all information are available through JMX, the easiest way to approach it is to write some scripts using Node.js. The architecture of the new Web UIs is ready for this.
        Hide
        Haohui Mai added a comment -

        Just to clarify, the old and the new Web UIs can coexist. You can still access the old web UI using the same URLs until the JSPs are removed.

        Show
        Haohui Mai added a comment - Just to clarify, the old and the new Web UIs can coexist. You can still access the old web UI using the same URLs until the JSPs are removed.
        Hide
        Haohui Mai added a comment -

        I think it might be worthwhile to start the conversation of deprecating the JSP web UI again. There are several jiras (e.g., HDFS-5661 / HDFS-5673) suggests that the design is broken in secure or HA set up:

        1. Redirection does not pass the HTTP authentication cookie along (as NN / DN are in different origins), forcing the DN to go through spnego again. It might not work for folks that implements their own authentication schemes.
        2. The URL contains the delegation token. The browser stores URL in its history. Anyone that has the access to the history lists might be able to steal the token.
        3. The URL in the DN's web UI contains the RPC address. There is a DFSClient in DN's web UI that takes the address and reads the contents of the HDFS. On the other hand, the JSP generates the web page merely based on the RPC address in the URL. The page could be wrong if a failover happens during the period, or it might lead to potential security vulnerabilities as there're no good ways for the DN to verify the parameters.

        Speaking of the lack of a text-based tool, I put up a tool that gets the information from the JMX. The tool is availalbe at https://github.com/haohui/dfshealth-cli. The tool is based on Node.js, but I do have a Java version that can be easily integrated into trunk.

        Show
        Haohui Mai added a comment - I think it might be worthwhile to start the conversation of deprecating the JSP web UI again. There are several jiras (e.g., HDFS-5661 / HDFS-5673 ) suggests that the design is broken in secure or HA set up: Redirection does not pass the HTTP authentication cookie along (as NN / DN are in different origins), forcing the DN to go through spnego again. It might not work for folks that implements their own authentication schemes. The URL contains the delegation token. The browser stores URL in its history. Anyone that has the access to the history lists might be able to steal the token. The URL in the DN's web UI contains the RPC address. There is a DFSClient in DN's web UI that takes the address and reads the contents of the HDFS. On the other hand, the JSP generates the web page merely based on the RPC address in the URL. The page could be wrong if a failover happens during the period, or it might lead to potential security vulnerabilities as there're no good ways for the DN to verify the parameters. Speaking of the lack of a text-based tool, I put up a tool that gets the information from the JMX. The tool is availalbe at https://github.com/haohui/dfshealth-cli . The tool is based on Node.js, but I do have a Java version that can be easily integrated into trunk.
        Hide
        Colin Patrick McCabe added a comment -

        The tool is based on Node.js, but I do have a Java version that can be easily integrated into trunk.

        Can you post the Java version? Perhaps in a new JIRA.

        Show
        Colin Patrick McCabe added a comment - The tool is based on Node.js, but I do have a Java version that can be easily integrated into trunk. Can you post the Java version? Perhaps in a new JIRA.

          People

          • Assignee:
            Unassigned
            Reporter:
            Haohui Mai
          • Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:

              Development