Clarification about new Cloud Fortified rules

I just saw that there are upcoming changes to the Cloud Fortified program https://developer.atlassian.com/platform/marketplace/changelog/#CHANGE-775 .

App base URLs

App healthcheck requests will be made to each distinct base URL that receives customer traffic, including the latest version of the app, the last patch version for each minor version with installations, and all regions for app versions that support data residency. The 99.9% 28-day target SLO will be applied to each app base URL individually.

I was wondering what is meant with base URL. Are you looking at the baseUrl as defined in the descriptor? Or each individual module entry?

In our case the base URL is usually just that - the base url and there isn’t anything served at that location so this change will cause an issue if the assumption is that there would be something there.

/Daniel

2 Likes

Hej @danielwester!

Yes, we are referring to the baseUrl in the app descriptor. But the URL we use for healthcheck requests is not the base URL itself, but rather the base URL followed by the healthcheck path.

We will obtain the healthcheck path by taking the Health check URL for this app that you provided in your App approval request, and “relativizing” it against the app descriptor base URL.

All this is only relevant to your app if you have ever changed its base URL.

Hi @epehrson ,
Can you illustrate that with an example?

@marc sure :slight_smile:

The app Example for Jira has two versions:

Not all customers have upgraded to version 1.1.0.

Example for Jira applied to the Cloud Fortified program after releasing version 1.1.0. In their App approval request, they provided the URL https://new-example.com/healthcheck as the Health check URL for this app.

To comply with the new requirements, the app must now make sure that their healthcheck path (/healthcheck) also corresponds to an endpoint for the base URL for version 1.0.0, since Atlassian will also start checking the URL https://example.com/healthcheck for the App availability metric.

ugh… For how long? We don’t have a way of forcing customers to upgrade.

Forcing app vendors to have to maintain legacy infrastructure seems really bad. I understand on paper why you want to do it, however it means that we can’t really add new health check functionality etc. This is bad.

To clarify what I mean - if I fork my code base and move over to a new provider as part of this - there may still be instances pointing to the old version - however they’re not paying and don’t have an active license (and don’t care about upgrading).

6 Likes

Also - if I’ve managed to move all of my customers off the 1.0 version but the marketplace still has that listed in the historical versions - it won’t be polled?

1 Like

We’re also interested in answers for the Daniel’s questions here. We have similar (or maybe the same) scenario:

  • had in the past app hosted on x1.y.z
  • in the meanwhile we’ve upgraded our app from free to paid, and we have moved to another domain (x2.y.z)
  • we did that domain switch 2 years ago (in an effort to ‘jettison’ non-paying customers staying on old version) - and since that we’ve stayed on the current domain

Should we expect that Atlassian will require us to keep x1.y.z/health_check endpoint running? Even if for 2 years nobody is using that old baseUrl? If yes, here are a few questions from me:

  • can we mark old versions as ‘private’ in Marketplace and make Atlassian skip testing health_check for such versions?
  • if all customers migrate to the new version, will Atlassian still be testing old health_check baseUrl?
  • are there any thresholds (request count, date, etc) at exceeding which Atlassian will stop testing old baseUrls?
1 Like

@danielwester, @stefan_hc we definitely don’t want to force you to maintain every version of your app. What we want to monitor is the versions of apps that are still actively used by our customers.

To clarify what I mean - if I fork my code base and move over to a new provider as part of this - there may still be instances pointing to the old version - however they’re not paying and don’t have an active license (and don’t care about upgrading).

This is one of the cases which should not be included in the requirements. It’s worth remembering too that we have process for retiring apps which can also be applied to app versions. If, as in your example, you move to a new hosting provider, and you still have customers on an old version with a different set of scopes, you are definitely within your right to request that Atlassian uninstall your app from those sites, relieving you of the requirement to maintain an app healthcheck endpoint for that base URL.

Also - if I’ve managed to move all of my customers off the 1.0 version but the marketplace still has that listed in the historical versions - it won’t be polled?

If there’re no usages of this version, it won’t be included in the requirements (as there’s no customer traffic).

We’re open to discussing it in detail if needed, just let us know via Marketplace message.

4 Likes

Aye. Makes sense now, thank you for clarifying the things.

How to determine if my app old version still does have some usage? Is it possible to obtain that stats somewhere, i.e. maybe from Marketplace reports? (assume that I no longer maintain app under old domain, so I can’t retrieve the traffic stats from there).

Thanks that makes sense. :slight_smile:

/Daniel

You can still see the Active Install counts for the particular version in the App reports on the marketplace.

Thanks!

Hello @danielwester
Just a question from my side to make sure I understood this correctly. In the previous version we had this base url: https://example.com/some_value/1.0/. Will the health check URL for this version be: https://example.com/healthcheck or https://example.com/some_value/1.0/healthcheck ?

Hi @ReiPano, since under the changed requirements, healthcheck URLs will always be relative to the app’s base URL, in your example the healthcheck URL would be https://example.com/some_value/1.0/healthcheck (where /healthcheck depends on what is specified by the app in the context of Cloud Fortified).

We will also follow up with you on your app approval request about your specific case.