Deprecation Notice: Removing filesystem access to Jira Data Center avatars and issue attachments

Jira Development Jira Data Center Announcements
, , , ,
1

:wave: G’day Atlassian community!

I’m Randy, a Senior Software Engineer on one of Atlassian’s Cross-Product Data Center teams.

Our team has been working hard on updating Jira to support storing attachments and avatars in an Amazon S3 bucket, rather than in the <sharedhome> directory. We believe this will greatly improve the scalability of the application, and reduce the burden of managing shared storage for our admins.

In preparation for this change, we had to deprecate a number of Java API endpoints related to attachments and avatars. This means that some features may no longer be available or may have changed, and we encourage all users to start familiarizing themselves with the updated API.

We apologize for any inconvenience this may cause in the short term, but we believe that the benefits of object storage support will be well worth it.

What is changing?

We’ve been able to provide alternative endpoints for some cases. However, there’re many places where you’ll need to refactor your app to access avatar and attachment data through the Jira API directly, rather than through direct filesystem access.

You can find a list of all deprecated API endpoints and more information on how to prepare your apps for the upcoming changes in Preparing for Jira 9.7.

When is it changing?

These deprecations take effect in Jira 9.7. Most deprecated endpoints, except for the getAvatarBaseDirectory() , will continue to work as expected until Jira 10, then we’ll permanently remove them from the API.

As we stop supporting getAvatarBaseDirectory() in earlier Jira versions, we recommend using the AvatarManager#readAvatarData() to access avatar data directly. The deprecated endpoints will continue to work as expected until Jira 10 is released.

We’re looking forward to your feedback!

We are excited about the future of Jira Data Center and the improvements that the integration with Amazon S3 will bring. Thank you for your continued support and trust in our team.

If you have any feedback regarding this feature, leave a comment below this post.

Cheers,
Jira Data Center and Server team

2

So what does this mean for those of us that are running Jira DC behind a firewall/proxy and don’t use Cloud at all?

What about Atlassian customers that may be running Jira DC in an air gapped environment?

Should it not be a choice to use Local storage or Cloud?

Not to mention the security implications for the storage of attachments outside the organization. It’s bad enough already that our corporate security team is still on our case about Log4J and Apache Commons. To which either of those do not seem to be on the list to be backported to existing LTS versions of Jira. So what’s the point of using LTS again? -.-

3

I think this has been poorly described, Atlassian are not deprecating storing attachments on disk.

They are deprecating apps making the assumption that attachments are stored on disk as in future they may be stored in S3.

Apps can no longer assume the files are on disk, they must use APIs that abstract the actual file location.

5 Likes
4

At least, that is my understanding.

@Randy could you please clarify.

5

Kudos to these changes :rocket: :metal:. I think since most customers already run a DC cluster on AWS this is a very nice feature regarding scaling and backup.

And just for those who are running Jira DC BareMetal, this could also be great by using for example minio https://min.io/ => A AWS S3 api compatible “server”. Means: You can run minio on another server to store these attachments on and it acts as an AWS S3 replacement.

@Atlassian: Would this be a valid approach? Or are there any special AWS S3 operations going on in the background that prevent us from using such drop-in-replacements?

Second question. Will there still be the shared-home with NFS just for cluster-index a.s.o?
And will there in some point of the future be a way to completely go for AWS S3 for index, clustering, a.s.o?

cheers,
Bernhard

2 Likes
6

That makes more sense. Thanks for the clarification.

7

Sounds good to me! Is there plans to also support Azure Blob Storage?

8

Is it safe to read avatar image from velocity template using the following link?

<img src="$baseurl/secure/useravatar?size=xsmall&amp;ownerId=$user.key" alt="$user.key">
2 Likes
9

We have an internal S3 compatible storage system, using Scality RING and some API that acts like S3, just not hosted in Amazon.

It would be super swell if Atlassian considered implementing this in a generic way. For example, Bamboo supports S3 storage but the URL is hardcoded to Amazon and thus we cannot use the feature on our internal “S3”.

2 Likes
10

Hey everyone, I appreciate your replies!

@Monty @rlander Let me clarify: Jira DC will still support storing avatar and issue attachment data in the shared home directory. However, we are also going to add the option to store these files in S3 object storage for our Data Center customers operating in the AWS Cloud.

This option means that apps can no longer assume that these files are accessible via the filesystem. That’s why we have deprecated these endpoints that provide a filesystem path.

@clouless Jira DC will still need a shared home directory to store the files you mentioned and many apps’ files when configured to use S3 for avatars and attachments. While we currently only have support for storing avatars and attachments in an S3 object store on the roadmap, we’re always looking for more feedback on what the next steps of our roadmap should be after we have delivered support for avatars and attachments.

@clouless @steve.behnke We will only officially support Amazon S3 at this stage, but internally we’ll be testing against a MinIO object store during development. This way, customers who want to use a third-party S3 API-compatible object store can do so at their own discretion. However, they should keep in mind that Atlassian support will not be able to troubleshoot any issues that may arise from using such an object store.

@MaximeBoyer We’re still exploring the best way to support object stores other than S3, so stay tuned!

@Holger Your code will be fine. The REST APIs won’t change :grin: The only affected apps are those that access avatar and attachment data directly via the filesystem.

4 Likes
11

That’s fine. It would be better for us than NFS. No promises, I get that – SpaceX would greatly appreciate that flexibility though.

2 Likes
12

How about providing an API that plugins could implement to provide custom storage?

All kinds of integrations come to mind. Besides Azure and GCP cloud storage, I can imagine Dropbox, Google Drive, Sharepoint, Box, etc.

1 Like
13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.