Details

      Description

      Implement logic for detecting offline and upgraded peers, render result in List Applications page (synchronous/background/ajax?)

        Gliffy Diagrams

          Activity

          Hide
          evzijst Erik van Zijst added a comment - - edited

          It's necessary to know whether a peer is online or offline, so we can prompt the user with the appropriate actions ("relocate server", "upgrade server"). This is not something we can do in APL in an application-independent way (some apps may not serve anything on their baseUrl, may have a proxy-server / load balancer / etc that still respond even though the app itself is offline, or a non-apl app may not be accessible at all).

          We should therefore add a getStatus() method to the SPI for app types to implement.

          The contract for detecting upgraded peers then becomes:

          if (peer is OFFLINE)
          {
            display "server offline" and "relocate" icon. "relocate" starts Relocate Wizard
          }
          else if (ServerID has changed)
          {
            if (peer UAL.version >= 3)
            {
              peer must be upgraded -> start full Upgrade Wizard
            }
            else
            {
              peer must have downgraded from UAL to non-UAL -> start ServerID Change Wizard
            }
          }
          
          Show
          evzijst Erik van Zijst added a comment - - edited It's necessary to know whether a peer is online or offline, so we can prompt the user with the appropriate actions ("relocate server", "upgrade server"). This is not something we can do in APL in an application-independent way (some apps may not serve anything on their baseUrl, may have a proxy-server / load balancer / etc that still respond even though the app itself is offline, or a non-apl app may not be accessible at all). We should therefore add a getStatus() method to the SPI for app types to implement. The contract for detecting upgraded peers then becomes: if (peer is OFFLINE) { display "server offline" and "relocate" icon. "relocate" starts Relocate Wizard } else if (ServerID has changed) { if (peer UAL.version >= 3) { peer must be upgraded -> start full Upgrade Wizard } else { peer must have downgraded from UAL to non-UAL -> start ServerID Change Wizard } }
          Hide
          tpettersen Tim Pettersen added a comment -

          Nice, looks good to me.

          Show
          tpettersen Tim Pettersen added a comment - Nice, looks good to me.
          Show
          evzijst Erik van Zijst added a comment - https://extranet.atlassian.com/display/~evzijst/AppLinks+Upgrade+Application+Link+workflow
          Hide
          fschmitz Felix Schmitz added a comment -

          For the following scenario: When relocating an application that is NON-UAL this can then lead to a server id change and this can then mean after doing the "relocation" (changing the url i assume), it will lead to a server id change which then will trigger this server id change wizard. I think from a user perspective it would be good if this is not a second wizard, just one transaction.

          Show
          fschmitz Felix Schmitz added a comment - For the following scenario: When relocating an application that is NON-UAL this can then lead to a server id change and this can then mean after doing the "relocation" (changing the url i assume), it will lead to a server id change which then will trigger this server id change wizard. I think from a user perspective it would be good if this is not a second wizard, just one transaction.
          Hide
          evzijst Erik van Zijst added a comment -

          I think from a user perspective it would be good if this is not a second wizard, just one transaction.

          Yes, agreed. We should attach the upgrade wizard to the relocation wizard.
          I'll mock out those scenarios.

          Show
          evzijst Erik van Zijst added a comment - I think from a user perspective it would be good if this is not a second wizard, just one transaction. Yes, agreed. We should attach the upgrade wizard to the relocation wizard. I'll mock out those scenarios.

            People

            • Assignee:
              evzijst Erik van Zijst
              Reporter:
              evzijst Erik van Zijst
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 6 hours
                6h
                Remaining:
                Remaining Estimate - 6 hours
                6h
                Logged:
                Time Spent - Not Specified
                Not Specified

                  hipchat-viewissue-panel

                  Error rendering 'com.atlassian.labs.hipchat.hipchat-for-jira-plugin:hipchat-viewissue-panel'. Please contact your JIRA administrators.

                    Who's Looking?