Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major 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

        Activity

        Hide
        Tim Pettersen added a comment -

        1 day UI, 1 day backend

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

          People

          • Assignee:
            Erik van Zijst
            Reporter:
            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?