glassfish
  1. glassfish
  2. GLASSFISH-19678

Temporarily remove cluster/HA management pages from console

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 4.0_b76_EE7MS5
    • Fix Version/s: 4.0_b82_EE7MS7, 4.0
    • Component/s: admin_gui
    • Labels:
      None

      Description

      For the Java EE 7 RI/SDK release, temporarily remove the cluster/HA management pages from the console since those features will be for evaluation only in that release.

        Activity

        Hide
        Anissa Lam added a comment -

        The work will include the following:

        1. comment out the plugin points in console-config.xml in the console-cluster-plugin module. This means
        – all clustering related screens (clusters/standalone instances/nodes, GMS config, availablility config) screens will be gone.
        – no target selection for resource creation, application deployment even though user may have created the cluster/instances using CLI
        – no availability option for deploying application.

        2. Filter out any other existing configs and only shows server-config.

        3. Ensure resource and application edit screen will not have the target tab. This tab exists depending on the cluster existence. Now, we want to suppress this even if cluster exists.

        Show
        Anissa Lam added a comment - The work will include the following: 1. comment out the plugin points in console-config.xml in the console-cluster-plugin module. This means – all clustering related screens (clusters/standalone instances/nodes, GMS config, availablility config) screens will be gone. – no target selection for resource creation, application deployment even though user may have created the cluster/instances using CLI – no availability option for deploying application. 2. Filter out any other existing configs and only shows server-config. 3. Ensure resource and application edit screen will not have the target tab. This tab exists depending on the cluster existence. Now, we want to suppress this even if cluster exists.
        Hide
        Anissa Lam added a comment -

        After spending sometime on this, I believe we should not remove the 'target' tab for any existing resources or deployed application.

        Doing #1 is easy and that's how console plugin is designed.
        Doing #2 is relatively easy, as there is capability built in for filtering when generating the tree node.

        I am recommending not to do #3 based on the following reasons. Note that #3 was not requested during the planning meeting.

        1. This target tabs is NOT related to clustering management. It reflects what the resources or application is targeted. If there is no cluster/standalone instance created in the domain, this target tabs/info will never be shown to user.

        2. If user is only using console, they will not see those tabs. The target tab will be there ONLY if the user really want to have cluster, they need to go through the trouble of creating and managing the cluster (since they can't see this cluster's config in console) in CLI, and then go back to the console to refer to it.

        3. Removing this tab means console will not be able to show accurate info about the resource/applications. If the user is using CLI to create a cluster, deploy an application to that cluster, i am not sure how the console can show this correctly. Showing the application is deployed, but without this target info will be the exact UI for a DAS only domain, user will think that the application is deployed to DAS when in fact its not.

        4. Too many pages UI and the logic behind this pages has to be modified. This is going to do more harm to the qualify of the console than removing them.

        5. If the goal is to discourage user to use the clustering feature in GF 4.0, then the following should be enough.
        a. no cluster / standalone instances/ nodes page appear in console
        b. only server-config is shown.
        c. do not allow user to target the cluster during application deployment and resource creation.

        Show
        Anissa Lam added a comment - After spending sometime on this, I believe we should not remove the 'target' tab for any existing resources or deployed application. Doing #1 is easy and that's how console plugin is designed. Doing #2 is relatively easy, as there is capability built in for filtering when generating the tree node. I am recommending not to do #3 based on the following reasons. Note that #3 was not requested during the planning meeting. 1. This target tabs is NOT related to clustering management. It reflects what the resources or application is targeted. If there is no cluster/standalone instance created in the domain, this target tabs/info will never be shown to user. 2. If user is only using console, they will not see those tabs. The target tab will be there ONLY if the user really want to have cluster, they need to go through the trouble of creating and managing the cluster (since they can't see this cluster's config in console) in CLI, and then go back to the console to refer to it. 3. Removing this tab means console will not be able to show accurate info about the resource/applications. If the user is using CLI to create a cluster, deploy an application to that cluster, i am not sure how the console can show this correctly. Showing the application is deployed, but without this target info will be the exact UI for a DAS only domain, user will think that the application is deployed to DAS when in fact its not. 4. Too many pages UI and the logic behind this pages has to be modified. This is going to do more harm to the qualify of the console than removing them. 5. If the goal is to discourage user to use the clustering feature in GF 4.0, then the following should be enough. a. no cluster / standalone instances/ nodes page appear in console b. only server-config is shown. c. do not allow user to target the cluster during application deployment and resource creation.
        Hide
        Nazrul added a comment -

        Anissa:
        What happens when developers use CLI to create a cluster and deploys an application?
        If we remove cluster plugin, I can imagine lots of GUI code path that we never tested before with target handling.
        Are we convinced that this is less risky?

        Alternatively..
        If we update the CLIs to have the warning for cluster related features, users will see these warnings when they use clustering, right?

        --Nazrul

        Show
        Nazrul added a comment - Anissa: What happens when developers use CLI to create a cluster and deploys an application? If we remove cluster plugin, I can imagine lots of GUI code path that we never tested before with target handling. Are we convinced that this is less risky? Alternatively.. If we update the CLIs to have the warning for cluster related features, users will see these warnings when they use clustering, right? --Nazrul
        Hide
        Anissa Lam added a comment -

        The cluster plug is for cluster, standalone instance and nodes creation and editing. Stop/start , setting its properties etc. Which is exactly what we want to achieve for 4.0.

        The target tab and target info is NOT part of the cluster plugin. So, if the user uses CLI to create a cluster and deploys an application, we will show it correctly, with target info regardless of existence of cluster plugin. Thats why i don't want to remove this target tab. Removing it is very risky and we will not be able to correctly reflect what the application is deployed to.

        For the console walk through, I will show 2 versions:
        option 1. with just the cluster plugin removed and other config filtered out.

        option 2: option 1 above Plus the removal of all the target tabs.

        -----------
        If CLI is changed to return warning when cluster, instances and nodes is created, then user will see this warning after the command is executed. But unless we change the Page Title help to remind user, they will only see that warning once. It will be out-of-way, out-of-mind.

        Show
        Anissa Lam added a comment - The cluster plug is for cluster, standalone instance and nodes creation and editing. Stop/start , setting its properties etc. Which is exactly what we want to achieve for 4.0. The target tab and target info is NOT part of the cluster plugin. So, if the user uses CLI to create a cluster and deploys an application, we will show it correctly, with target info regardless of existence of cluster plugin. Thats why i don't want to remove this target tab. Removing it is very risky and we will not be able to correctly reflect what the application is deployed to. For the console walk through, I will show 2 versions: option 1. with just the cluster plugin removed and other config filtered out. option 2: option 1 above Plus the removal of all the target tabs. ----------- If CLI is changed to return warning when cluster, instances and nodes is created, then user will see this warning after the command is executed. But unless we change the Page Title help to remind user, they will only see that warning once. It will be out-of-way, out-of-mind.
        Hide
        Anissa Lam added a comment -

        I need clarification of what needs to be done in console now that the decision is to give warnings to user when they try to use clustering.
        I see the following needs to happen in the console:

        1. All pages relating to clustering support (Nodes, clusters, cluster instance, standalone instance) should include a warning in the page title.

        2. when creating Nodes, clusters clustered instance, standalone instance, backend will return WARNING as the status, and that warning will be shown to user. Console should be able to do this without any modification, but need to be tested.

        3. There is Availability Service tree node under cluster's configuration, which shows the following pages: Availability Service, Web Container Availability, Ejb Container Availability and JMS Availability. Do I need to hide these tree node and pages ? Or page titile warning is enough ?

        4. During deploy and redeploy, there is the checkbox for 'availability enabled', should this be hidden ?

        Show
        Anissa Lam added a comment - I need clarification of what needs to be done in console now that the decision is to give warnings to user when they try to use clustering. I see the following needs to happen in the console: 1. All pages relating to clustering support (Nodes, clusters, cluster instance, standalone instance) should include a warning in the page title. 2. when creating Nodes, clusters clustered instance, standalone instance, backend will return WARNING as the status, and that warning will be shown to user. Console should be able to do this without any modification, but need to be tested. 3. There is Availability Service tree node under cluster's configuration, which shows the following pages: Availability Service, Web Container Availability, Ejb Container Availability and JMS Availability. Do I need to hide these tree node and pages ? Or page titile warning is enough ? 4. During deploy and redeploy, there is the checkbox for 'availability enabled', should this be hidden ?
        Hide
        Tom Mueller added a comment -

        The decision on this is to do GLASSFISH-19772 instead.
        So this issue will not be fixed.

        Show
        Tom Mueller added a comment - The decision on this is to do GLASSFISH-19772 instead. So this issue will not be fixed.

          People

          • Assignee:
            Anissa Lam
            Reporter:
            Tom Mueller
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: