Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.0 - Iteration 14
    • Component/s: core
    • Labels:

      Description

      See: https://extranet.atlassian.com/display/~evzijst/AppLinks+Upgrade+Application+Link+workflow

      Relocating a Peer

      • From the perspective of the relocatee:
        • Nothing changes, but modifications to TA/OAuth will break during headless reciprocal actions (as the peer will use the old baseUrl)
        • Even if we detect changes, what can we do to fix it on the peer?
      • From the perspective of the peer:
        • The List Applications page gets Conn Refused and renders "Peer Down or Relocated" link, or the admin actively clicks on "Configure"
        • Brings up configure dialog with rpcUrl editable
        • User types new URL and we retrieve manifest through the ApplicationType class:
          • If new manifest reports a different app type, we barf (JiraApplicationTypeImpl.getManifest() attempts to download first)
          • On conn refused we don't barf, but accept the new url
        • If the new manifest has a different server id (will happen with non-UAL peers, or if the UAL peer is offline, or if the user mis-types the URL)
          • Maybe simply change the server id in the db and emit an event. After all, a mere relocation would not change app type, auth config or entities
          • ^--- fail, because might be UAL peer that is temporarily offline, so don't do anything and rely on server id detection in List Applications
          • Conclusion: don't make state changes to keep the process reversible

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            tpettersen Tim Pettersen added a comment -

            1 day UI, 1 day backend

            Show
            tpettersen Tim Pettersen added a comment - 1 day UI, 1 day backend

              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 - 1 day, 4 hours
                  1d 4h
                  Remaining:
                  Remaining Estimate - 1 day, 4 hours
                  1d 4h
                  Logged:
                  Time Spent - Not Specified
                  Not Specified

                    Who's Looking?