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

          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?