RFC-56: Data Residency for Forge Remote

General Request for Comments (RFC)
, ,
1

RFCs are a way for Atlassian to share what we’re working on with our valued developer community.

It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.

Please respect our community guidelines : keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!

Summary

Data Residency for Forge Remote aims to enable Forge remote apps to meet data residency requirements by supporting remotes with region-specific data storage capabilities. This project responds to the increasing need for compliance with regional data residency regulations, as well as customer demands for data storage localisation to improve performance and ensure privacy.
We will address two aspects of Data Residency for Forge Remote, realm pinning and realm migrations.

Publish: Jul 29, 2024

Discuss: Aug 11, 2024

Resolve: Aug 18, 2024

Problem

App partners are looking to adopt Forge Remote; however, many of these apps require storage of user data, making data residency a critical requirement for customers. Customers need data residency for reasons such as complying with local privacy and security laws or reducing latency. Currently, Forge Remote does not support data residency, preventing these apps from transitioning to Forge Remote and meeting customer expectations and regulatory requirements.

Proposed Solution

The solution will allow Forge apps to specify multiple remotes, each with defined region-based URLs for data storage. Only remotes declaring storage operations with EUD will be required to support region-based URLs, providing clear communication to customers about data residency and storage locations.

An example manifest design illustrating the proposed changes is provided below, closely mirroring the Connect method for handling data residency. This design choice facilitates a smooth and straightforward transition from Connect to Forge Remote. In the example manifest, each remote includes a default base URL and region-based URLs supported by the app. A separate migration module is defined, directing migration hooks to a specific remote. This setup allows for flexibility in data management and compliance with data residency requirements.

....
permissions:
external:
  fetch:
    backend:
      - remote: forge-remote1
remotes:
  - key: connect-remote
    baseUrl:
      default: "https://mr-connect.com"
      us: "https://us-mr-connect.com"
      eu: "https://eu-mr-connect.com"
      au: "https://au-mr-connect.com"
    operations:
      - storage
      - fetch
    storage:
      inScopeEUD: true
  - key: forge-remote1
    baseUrl:
      default: "https://ms-forge1.com"
      us: "https://us-ms-forge1.com"
      eu: "https://eu-ms-forge1.com"
      au: "https://au-ms-forge1.com"
    operations:
      - storage
      - fetch
    storage:
      inScopeEUD: true
  - key: dare-remote
    baseUrl: 
      default: "https://dare-migration.com"
      us: "https://us-dare-migration.com"
      eu: "https://eu-dare-migration.com"
      au: "https://au-dare-migration.com"
    operations:
      - fetch
modules:
  migration:
    dataResidency:
      remote: dare-remote
      migrationPath: "/migration-hook" //This can be optional. Hooks could directly go to the baseUrl
      maxMigrationDuration: 3
app:
  connect:
    key: mr.connect
    remote: connect-remote
...

Considerations

  • All remotes with the storage operation defined and inScopeEUD true must support the same region-based URLs to be eligible for realm pinning.
  • All remotes egressing inScopeEUD data need to support the same regions to be eligible.
  • If any remote doesn’t have storage and inScopeEUD but they declare region based urls for compute purposes, they will need to support all the regions that are declared in storage remotes
  • Apps storing data both on Atlassian (in hosted storage) and externally via a remote will be eligible for realm pinning, provided the remote supports region-based URLs.
    • A new option will be available in the Privacy and Security tab to inform customers of this setup.
    • Changes to the Privacy and Security tab will ensure customers are informed about what each partner constitutes in-scope and out-of-scope EUD.
  • Apps storing EUD on Atlassian with remotes not storing EUD will continue as usual, with hosted EUD pinned to the product’s region.
  • Migration hooks will support Forge Invocation Tokens (FIT) and not Connect JWTs authentication.
  • Note: Your data residency migration path, does not have to point to a separate remote as shown in the example.

Major Version changes

We have identified a number of actions that would require a major version upgrade for customers. I can empathise that the current major version upgrade experience is a pain point in Forge currently. Atlassian are currently looking into the problem space, however, we will not be addressing that issue with this piece of work.

The actions that will require a major version upgrade are:

  • Adding regionBaseUrls
  • Changing existing remote baseUrl or regionBaseUrls
  • Changing the operations of an existing remote and adding storage with inScopeEud true
  • Removing regionBaseUrls

Out of scope

We have a number of features we would like to include in this pass of Data residency, however, for this first iteration we have a number of features which we will not be addressing in this immediate piece of work.

  • Apps using direct URLs through external → fetch will not be eligible for pinned status due to the support of wildcard URLs
  • Multi-environment support in a single manifest.
  • Realm Persistence feature. We will be addressing this feature as a fast follow.

Asks

While we appreciate any feedback on this RFC, we are particularly interested in understanding:

  • What challenges do you anticipate with the proposed data residency requirements?
  • Would this solution meet your requirements in supporting data residency on forge remote?
  • Are there aspects of data residency compliance that you feel are not adequately addressed in this proposal?
  • Do you have any questions regarding this solution that aren’t addressed here?
5 Likes
2

Hi @DanielReed,

Thanks for this RFC.

I just released a Compass app that uses a Jira connect app as remote for which I’m currently building Data Residency and Migration, so this RFC is well timed and much appreciated.

Just a quick question on the migration module.

It lists a maxMigrationDuration element.
What does the number of this element mean? I’m assuming its not seconds, or weeks, but hours and days seem likely candidates for the meaning of the value. If memory serves, the Forge Invocation Token is only good for 1 hour, if the migration is taking longer are apps expected to refresh the token by themselves? Or will the migration token be valid the entire duration of the migration?

Also, does it have the same, schedule, start, status, commit, rollback approach as for connect? My Compass only has compute in Forge Remote, so migration will be instant from a Compass perspective, but for the Jira app it will take a lot longer and will require additional steps and resources to make sure no data is lost.

Can you elaborate on the process for the data migration, especially how (dis)similar it is to connect.

Cheers,
Mark

2 Likes
3

Hi Mark,

Thanks for your questions, and glad to hear you’re interested in data residency for forge remote!

The maxMigrationDuration element will look new. This is actually a feature that we’re looking to release in Connect in the coming weeks, and we will be looking to build this into Forge Remote DaRe in the initial build. This is a way for partners to declare how long they expect the migration to take, in hours.

The current timeout for an OAuth token is currently 1 hour, however, for all migration hooks, schedule, start etc, we will be utilising Forge Invocation Tokens (FIT) which have a timeout of 5 seconds for events and scheduled triggers. We do not anticipate any requirements for a long life token for migrations.

Would this align with your requirements? or do you foresee a requirement for a long life token for the duration of the migration?

Regarding your second question, our main focus is on ensuring a seamless transition from Connect to Forge Remote, minimising the effort required by partners. In line with this goal, the compulsory hooks and payloads will mostly remain unchanged. The only potential change under consideration is the addition of a unique identifier, such as migrationJobId, to the migration hook to improve incident management.

Cheers,
Daniel

4

I this something that is in a RFC or EAP or otherwise documented? Or did I simply miss it.
I welcome the feature to allow for shorter migration windows instead of a fixed 24 hours window. But not migrations are created equal, some will take minutes, others will take hours, maybe even a whole day, how will the migration process handle if a migration is taking longer then the hours set in maxMigrationDuration? And on the flip side, how will the process handle migrations done well within the maxMigrationDuration, say the max is set to 5 hours but the migration is done within the first hour?

In reading your response I remembered that the cloud instance is down during a migration, so the default token timeouts are fine.

So I only need to allow the ForgeInvocationToken and authentication for the migration webhooks instead of the JWT token to support Forge Remote migrations?

5

Hi Mark,

Apologies, there isn’t a public RFC or EAP. We have only announced that we are working on the migration downtime issue in the last couple of webinars. I will link to these resources below. We’re going straight to preview early next week with this feature. I will send you a link to the announcement when we go live.

We will go into more detail when we announce the preview next week, however, I can answer a couple of your questions here as Forge Remote DaRe will follow the same logic.

  • maxMigrationDuration is defined in hours, and can be set from 0.5 hours to 24 hours.
  • If a migration takes longer than the defined maxMigrationDuration, the migration will timeout and fail.
  • In the event a migration takes less time than the defined maxMigrationDuration, if all migrations for that customer are finished, they will be brought back online earlier.
  • A migration downtime for a customer is the highest maxMigrationDuration provided among Apps in the migration.
  • If maxMigrationDuration isn’t defined, the current default of 24 hours will apply.

So I only need to allow the ForgeInvocationToken and authentication for the migration webhooks instead of the JWT token to support Forge Remote migrations?

That is correct. The only consideration would be if you decide to use multiple remotes in Forge, you’ll need to make sure that all in-scope remotes should migrate using the single data residency remote.

Webinars:
Q1, Recap
Q2, Recap

Cheers,
Daniel.

6

Hi @DanielReed

Thanks for the clarification, and the links. I’ll keep and eye out for the preview.

That is correct. The only consideration would be if you decide to use multiple remotes in Forge, you’ll need to make sure that all in-scope remotes should migrate using the single data residency remote.

Lovely that would make it a lot easier to implement.

Cheers,
Mark

7

Hello @DanielReed,

First of all, thanks for this RFC.

We are currently starting to support Data Residency in one of our Connect apps. But, at the same time, we are just working in another app with the Connect in Forge approach. For both things, this RFC is well timed for us too, so we can plan to work in Data Residency support for the remote of the Connect in Forge app in the next months.

I had a light talk with my teammates that are currently working in the Data Residency for the Connect app and it seems to be really similar to support different realms for remotes too. We are currently working on deploying our app on different realms and they told me this seems to work really similar here.

Moreover, I cannot see a major problem with realm migration, but maybe we will find it when we work on that for our Connect app, which will happen in the next months. If there may be the same triggers, I think working with the Forge Invocation Tokens will not be a problem.

Please, let me know if I’m missing something here or we should take special care with something that behaves differently than in Data Residency support for Connect apps.

Have a nice day!

8

Thank-you all for your valuable feedback and questions. We truely appreciate it.

Based on your input, we will be proceeding with this design for Forge Remote Data Residency.

Next quarter we’ll be reaching out to partners interested in joining the EAP for Pinning, so please stay turned for that.

I’ll now close this RFC.