Back-porting Connect app to P2 - datacenter compatibility

I am working on back-porting a Connect app to P2 and have some questions/concerns regarding datacenter compatibility.

Some of my Connect code relies on the security context received in the installed lifecycle event, namely host client_key and the shared secret. To make things work the same way in P2, I have been thinking of creating a similar security context when the P2 app is installed and save it in the DB.

  1. If I create a component that installs/uninstalls the security context and implements InitializingBean and DisposableBean, can I be sure that the two implemented methods run only once on plugin install/enable or uninstall/disable in a clustered environment?

  2. What value to use for client key? I am looking for a constant value that is the same for all nodes in any deployment scenario (normal and datacenter). I am contemplating on whether it is safe to use Server ID as an identifier for an installation, however, this article on “What is Server ID?” says:

    The Server ID is the same for all servers in a cluster (Confluence only)

    If I understand this correctly, it is not safe to use Server ID as “client key” in P2 because different Jira nodes in the same datacenter installation could potentially have different Server IDs.

    Another option might be to simply generate a client key value or use a hard-coded constant. This implies that there must always be just one security context record in the database (per Server/datacenter installation). This would be required because there is no data in the security context that links it to the Jira Server/datacenter installation that would allow inferring the security context.

    Does anyone have an opinion on this or knows a better value to use that works in all deployment scenarios?

Hope my ideas and concerns are clear. Otherwise, I am happy to clarify. Appreciate any input, thanks!

Not sure what you’re trying to do, but DataCenter(and Server) apps are single tenant. They’re only installed in a single instance at a time (even if it’s clustered through DC).

If I create a component that installs/uninstalls the security context and implements InitializingBean and DisposableBean, can I be sure that the two implemented methods run only once on plugin install/enable or uninstall/disable in a clustered environment?

The methods will be run on each node when the app is loaded. You can use the atlassian-scheduler to set a job that’s only triggered once in a cluster though.

What value to use for client key? I am looking for a constant value that is the same for all nodes in any deployment scenario (normal and datacenter). I am contemplating on whether it is safe to use Server ID as an identifier for an installation, however, this article on “What is Server ID?” says:

Not quite sure what you’re after here. The instances are single tenant so you can create anything you want and store it in the database and have it be available across the entire cluster.

Thanks for your help @daniel and sorry for the lengthy question. I should have left out some of the implementation details and boil it down a bit more to the essentials.

In essence, I am looking for a way to save a secret to the DB (if it is not already there) once when the plugin is installed/enabled.

I have been reading a bit more on atlassian-scheduler and events and I think I found a relatively simple solution:

This page on plugin system events suggest two ways to do this (the second one being the preferred one)

  1. Listen to PluginEnabledEvent and then run the operation, or
  2. Do the operation the first time it is used/called

In my case, the second option should work quite well. The first time I try to read the secret from the DB it won’t be there. In this case, I will generate and store it (for DataCenter I assume I need a lock here).