I got 2 questions regarding the behaviour of an app in a datacenter environment
a) Enforcing the datacenter license
From september 2019 onwards, datacenter will enforce the fact that all the apps on the instance must be datacenter approved.
Question - Will the customer be able to use the server version until the instance has been upgraded to a particular version of Jira (which one) or will the app stop to work on September 3, 2019
b) What happens when …
It is currently possible to load 2 artefacts of the same version on the marketplace - the server and the datacenter edition.
There are a couple of permutations possible, and we are wondering how the app will behave
Server App - on server instance - using a server license
Server App - on datacenter instance - using a server license
Server App - on server instance - using a datacenter license
Server App - on datacenter instance - using a datacenter license
Datacenter App - on server instance - using a server license
Datacenter App - on datacenter instance - using a server license
Datacenter App - on server instance - using a datacenter license
Datacenter App - on datacenter instance - using a datacenter license
Hi @francis, thanks for these great questions about Data Center apps and licensing. I’ll take them one at a time.
It’s important to make a distinction between the version of the app the customer has installed (binary file) and the type of license they have (license key).
In a DC environment, customers can install and use server app versions indefinitely. This is true today and it will be true after September 2019 as well. There is no requirement that installed binaries have to be DC approved, and we have no plans to add that. Non-DC-approved apps show a warning message in UPM, but they remain fully functional.
There are two cases where the customer will have a server version installed in a DC environment:
When there is no DC-approved version of the app available in Marketplace
When there is a DC approved version, but the customer yet hasn’t updated to that version
In both cases the customer can continue using the server version indefinitely, and upgrading the host product (e.g. Jira) shouldn’t trigger any problems - unless of course the installed app isn’t compatible with the updated host product version.
In fact, for a given app key, there can only be one artifact installed on a customer instance. So the server and DC versions can’t be installed at the same time.
I’ll try this as a table, since I need the markdown practice.
#
App binary
Host instance
License type
Result
1.
Server app
Server instance
Server license
valid
2.
Server app
DC instance
Server license
valid
3.
Server app
Server instance
DC license
valid
4.
Server app
DC instance
DC license
valid
5.
DC app
Server instance
Server license
valid
6.
DC app
DC instance
Server license
valid (license start date < 2019-09-03)
invalid (license start date >= 2019-09-03)
7.
DC app
Server instance
DC license
valid
8.
DC app
DC instance
DC license
valid
“Valid” means that UPM will consider the license to be valid and therefore the app will be functional. The only case where the license will be invalid is #6, when the start date on the license is 2019-09-03 or later.
Is this a change in policy from the initial announcements? I have a real issue with option 2.
The launch blog here:
States :
"In addition, effective September 3, 2019, Data Center customers will not be able to renew maintenance for Server versions of apps for which there are Data Center approved versions. At that time, they will be required to purchase Data Center approved apps where available. "
My emphasis in bold. What Dave Parrish has written in this community post seems to contradict this statement from launch. i.e. if I take the blog message then in cases where both DC and server apps are available on marketplace, then option 2 above is invalid after September 3rd.
My expectation from the launch positioning… is that customers from September will be forced into running DC versions of our applications on DC. … and that will happen either at upgrade of the Atlassian product, or at renewal.
This could really do with a timeline. If a customer has a server version of the app that they now own in perpetuity… then yes they should be able to use it in the version that was supported on September 2nd. but if they upgrade Jira instance to a newer version… I’d expect a customer to need to upgrade to a newer version, and by extension a DC version of the plugin. Otherwise as a vendor I am in the situation of having to support both server and DC versions of the app on data centre for multiple years. and that is… not my original understanding of this programme.
So talking purely about DC instances, in cases where both server and DC versions of an app are available… I was expecting that:
all customers running server versions of the apps are to be forced to purchase the DC version of the application on their first upgrade of Jira DC after September 3rd? i.e. an upgrade forcing function due to lack of plugin compatibility with the host app. i.e options 2 & 4 above will be forced to move to option 8.
no new server apps should work on a DC instance after Sept 3rd? i.e. option 2 above is wrong and should never happen after Sept 3rd?
I also have a question related to @dparrish’s table above, related to the differences between rows #2 and #6.
What is it that allows the UPM to identify an app binary as a “server app” or “DC app”? Similar to what I imagine a lot of other vendors are doing, we have identical binaries for both Server and DC editions.
Does a “DC app” binary simply mean “an app having the Data Center compatible flag in the plugin XML”? If so, from the point of view of UPM, wouldn’t this mean that all of our customers (using any post-DC launch version of our app) are considered as using a DC binary, regardless of license purchased? And this would imply that we only need to consider rows #5-8 for those customers?
Apologies for the delay. I was on leave last week. I’m working with engineering to confirm the implemented functionality here. I’ll have an update here with some clarity asap.
We also have a detailed comms plan for customer and vendors due in the coming weeks.
Thanks Ben.
Is there an internal communications plan for inside Atlassian as well?
I am only slightly joking- my perception of the communication coming out of Atlassian … is that I have heard multiple different versions of what is going to happen. i.e. it is muddled. I’m not surprised at that at all, there are many combinations possible of renewal/upgrade etc.
Apologies for the delay on my response here. There are some technical intricacies that we needed to chase down and confirm before we could provide details of the implementation with 100% confidence.
What we stated in the original post holds true:
“In addition, effective September 3, 2019, Data Center customers will not be able to renew maintenance for Server versions of apps for which there are Data Center approved versions. At that time, they will be required to purchase Data Center approved apps where available.”
Dave’s table above also holds true. The complexity is in the mode of distribution. If you are an app vendor that distributes your app with the same artifact, that app is essentially a DC app running on a DC instance. Which will, in turn, be enforced by UPM. Even though it was installed as a Server App.
You can test this today if you install a license with a start date post the enforcement date. If you distribute 2 separate artifacts, we will recommend making some changes to your app in order to ensure your app is covered by enforcement. The reason this is the case is that many DC instances sit behind the firewall and there is no reliable way for the app to know that a DC Version exists. Hence it is opt-in by the vendor when their server artifact is different from their DC.
We have a full set of vendor comms due out in the next couple of weeks that will cover this in a lot more details such as our recommendation for implementing a license check with a Server app on a DC Instance the proposed copy, what purchasing impacts this will have and a full timeline with a diagram
Let me know if this makes sense, or if you have additional questions.
Thanks for the clarifications. I do have an additional question:
Dave’s table above also holds true. The complexity is in the mode of distribution. If you are an app vendor that distributes your app with the same artifact, that app is essentially a DC app running on a DC instance. Which will, in turn, be enforced by UPM. Even though it was installed as a Server App.
I’m still a little confused. If I’m distributing only one artifact, you wrote that it will essentially be considered a DC app running on a DC instance (ie. look at only rows #6 and #8 of Dave’s table above).
This behavior is fine if the customer is, in fact, running a Data Center host product.
But what about customers running that same binary on an actual Server host product using a Server license? Will they get sucked into the licensing behavior on row #6 too, even though they’re not actually running DC and their license should not be invalidated after September?
You can test this today if you install a license with a start date post the enforcement date.
Is it possible for Atlassian to produce timebomb licenses that meet these criteria (both a Server and a Data Center app license)? I couldn’t find anything relevant in the usual place.
edit:
To expand on myself here a bit. Getting time bomb licenses before the Sept date would be great - especially if had pretty much had all of the scenarios in the
I’m not sure if you’re in the right forum for your question as this is mostly about the development of Atlassian Apps.
Case 2: Server app, DC instance, Server license works fine in our experience.
What is the purchase date/renewal date of the license. Is it after 2019-09-03?
You might want to contact the app vendor or open a ticket with Atlassian as they are the ones that can help you with license issues.
valid
invalid (license start date >= 2019-09-03)
