[Suggestion] - Always write Jira's dbconfig.xml when starting a new Pod

[dennisfischer]

Suggestion

Problem

As a user it is possible to run into wrong information in the dbconfig.xml. As a result, the Jira pod will not start (no connection possible) or will start, but show the Setup Jira dialog.

There are a few ways to run into an inconsistent state when following the recommended configuration of having a persistent local-home directory.

1. Deploy via Helm without database configuration in values.yaml. Configure Jira. Spawn a second node. The second node will start with an empty dbconfig.xml and will show the Jira Setup dialog again.
2. Deploy via Helm and set the database url/credentials in the values.yaml. Try to switch to a new database by changing the database configuration in Helm's values.yaml. Trigger an upgrade of the release via Helm. Recreated Pods will still connect to the old database, because dbconfig.xml is not overwritten.

A persistent local-home directory is recommended in the documentation:

Whilst the data that is stored in local-home can generally be regenerated (e.g. from the database), this can be a very expensive process that sometimes requires manual intervention.

Current Workaround

Up to two additional steps have to be performed currently, to get back to a consistent state:

• Configure the database in Helm's values.yaml
• Delete the PersistentVolumeClaim which is used for the local-home of a Pod.

Suggestion

The root cause is associated with Jira's container image, specifically the entrypoint python script which can be found at https://bitbucket.org/atlassian-docker/docker-atlassian-jira/src/master/entrypoint.py. The dbconfig.xml file is intentionally not overwritten.

A solution could be to regenerate the dbconfig.xml if the database is configured in the values.yaml. This could be done in the container image (e.g., always regenerate if environment variables are set) or the StatefulSet could contain an additional initContainer which "deletes" the existing dbconfig.xml beforehand.

This problem could also affect Confluence or Bitbucket, but I did not test it.

Product

Jira

Code of Conduct

• I agree to follow this project's Code of Conduct

[errcode1202]

Hi @dennisfischer,

Thanks for raising this. As you've pointed out, this scenario can be addressed by ensuring the values.yaml is configured with the database properties:

Up to two additional steps have to be performed currently, to get back to a consistent state:

• Configure the database in Helm's values.yaml

The database is in fact a required pre-requisite, which is documented:

• Prerequisite guide - Provision DB
• Install guide - Configure DB

Database requiredness is also called out in the values.yaml itself.

There is an expectation that (at least for enterprise deployments) that the values.yaml is fully configured with all of the required properties, or else the deployments mileage may vary. As a result we're going to close this issue.