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?