This page https://developer.atlassian.com/cloud/jira/platform/data-residency/
Says
EU: In-scope data is hosted within the Dublin AWS regions
So if the data is in Germany they don’t count as EU? #confused
From my understanding, this is just where Atlassian stores their EU data, not which AWS Regions are allowed for EU.
2 Likes
Hi @SeanBourke ,
I have a question about the app descriptors for Connect (i.e. atlassian-connect.json).
Which descriptor (i.e. the descriptor from which region) is used for the marketplace version and update checks?
What happens if the regional app descriptors differ?
Hey @marc,
You should only need to define one single app descriptor for your Connect app. This descriptor should include the regionBaseUrls for each of the regions which are supported, with a different baseUrl which defines where Connect will route any app traffic for customers who have installed the app within that region.
This would be the same descriptor which is used today, as there’s no need to define a descriptor for each of your regions - your descriptor should include information about which regions are supported and where traffic should be routed for these.
Thank you for the explanation. I was under the impression all regional app instances needed to serve atlassian-connect.json.
Hi,
We were trying to implement data residency in a connect app and stumbled upon a situation that upon finding this thread we realized it had already been identified and has been described above as “realm pinning persistence for app re-installs”.
When an app is re-installed we need Jira to keep calling the app through the same URL as before it was uninstalled, even if the app wasn’t pinned.
And even if we define a “global” region in the app descriptor, Jira will pick another region if the app isn’t pinned into a specific region and is set to the Global region.
Are there any plans to change this?
Best regards,
Sérgio Vieira
4 Likes
Hello,
Can you clarify (and add it to documentation) on which base url the webhooks are called (global/target realm/source realm) and whether all webhooks are called on the same base url during specific migration?
Hey @sergio.vieira,
Thanks for sharing your concerns and understand the constraint. We have previously shared details about our thinking around this. Our primary concern is the diversity and complexity of implementations of realm pinning and realm migrations to date - we need to consider a solution which is suitable for developers who may rely upon this logic for their use cases as well.
While I don’t have any timing about when we’re likely to deliver this, I can commit to us utilising the RFC process to ensure that we assess the feasibility of the solution with the developer community and source their feedback to ensure we’re heading in the right direction.
1 Like
Hey @lexek-92,
Thank you for your feedback, appreciate there is an opportunity to make this clearer within our documentation.
All hooks for the Data Residency lifecycle events will be emitted to the original realm (that is, the realm which the customer requesting the migration is currently located), including the /commit hook. If the migration is committed, then once the host product is made available again, all subsequent traffic for that customer will be directed to the target realm (the one which has been migrated to). If the migration is rolled-back, then all subsequent traffic once the host product is made available again will be directed to the original realm.
1 Like
Hi Sean,
Is there a retry policy for /rollback webhooks? In broader terms, what happens if rollback returns non-2xx response?
Also, what is expected behaviour if /status returns non-2xx response and/or response in non-compliant format? Will it also cause a rollback?
Is there maybe a possibility to consider retry for intermittent 502/503 responses?
Hi,
- Is there any way to test Data Residency on a dev instance? If i upload an app by providing the atlassian-connect.json file will it be forwarded to one of the regions defined in the regionBaseUrls (defined in atlassian-connect.json)? Is there any way to debug how Jira forwards the install request?
- if the app doesn’t yet support realm migration will it still be eligible for Data Residency?
Hey @JulianVasaK15t,
Thanks for the questions, I’ve provided some answer in-line below. Hopefully these help.
Data residency on a dev instance should work similarly to any other instances. If you have pinned the product to a region which is supported in you app’s descriptor, you should see traffic for a new installation directed to that regionBaseUrl. If you haven’t pinned the product, the region will be selected based upon the product provisioned region (shard) if it is supported in your descriptor. If you do not support the product region or the provisioned region, the requests for a new installation should be directed to your baseUrl.
Unfortunately the determination of this routing is performed at installation time and cannot be debugged externally; however you can see the current location of an app following its installation in the data residency app details screen.
An app which supports realm pinning but not realm migration may appear to customers as either Pinned (when it is already installed in the same region as the customer’s product) or Not Eligible (when it is hosted in a different region to the customer’s product, or does not support region of the customer’s product). Once realm migration is supported, if the customer’s product region is supported, the app will appear in Eligible and be available to have a move requested.
1 Like
Sorry @lexek-92, I missed this query.
/rollback currently implements retries to notify your app, reattempting twice after the initial failed attempt.
We’re currently improving the retry behaviour to other polling hooks to ensure that transient errors are less likely to result in a complete migration failure. Where an error code is present we won’t attempt any retries; however all other endpoints which could result in failure will retry to ensure best-efforts to not fail the migration.
Hi @lexek-92,
An update on this - we’ve released some improvements to the retry mechanisms for the data residency migration hooks. The related documentation has been updated to reflect this improved behaviour.
Hi @SeanBourke,
Are there any updates on realm persistence?
Hi @lexek-92,
The team is currently working on data residency realm persistence, with plans to make it available for use in the first quarter of next calendar year. As we get closer to this, I’ll share more details.
Regards,
Sean
1 Like
Please could a lovely Atlassian team member confirm that the following is okay as long as it is clear in our Data Residency Policy?
{
...
"regionBaseUrls": {
"US": "https://us-east-and-west.aws.region.app.com",
"EU": "https://frankfurt.aws.region.app.com",
"DE": "https://frankfurt.aws.region.app.com"
}
}
It would still match up with what realms customers are shown when they select a location for their Atlassian products. EU doesnt have to mean ONLY Dublin AWS region, right?
2 Likes
Hey @mike1,
For Atlassian products, we state that we may store products which are in the EU in either the Frankfurt or Dublin region.
While there are no technical validation or constraints against utilising the same region for these two regions, it is up to you / your company to make the determination of how this would be defined for your apps, as you will have independent DPAs / data agreements with your customers.
4 Likes
Yep, understood, just making sure there were no constraints from Atlassian that I had not found through documentation. Thanks for the clarification!
1 Like
Hey @SeanBourke,
another quick question about the data residency migration process:
As far as I understand, no lifecycle events like /installed, /uninstalled, /enabled are called on either region.
This means that we have to move over the information given in the /installed hook with the other data and that we can trust that the product will use the same clientKey etc. when communicating with the “new” region.
Is my understanding correct?
Thank you for the clarification! Might be added to the docs.