[Suggestion] - Config files should be mounted configmaps

[mumbley]

Suggestion

In the course of deploying the Jira helm chart as a 3 pod cluster, I am forced to do the following (limiting steps fro brevity) Install the chart

• Log into the application
• manually configure Postgres (there will be another ticket for this because the schema is not configurable in values.yaml
• Manually select other options
• Change the values.yaml replicas: 2 https://atlassian.github.io/data-center-helm-charts/troubleshooting/LIMITATIONS/#jira-and-horizontal-scaling
• re-run the chart
• kubectl exec -ti into the second container and manually run the configuration tool https://confluence.atlassian.com/adminjiraserver/using-the-jira-application-configuration-tool-938847894.html
• Repeat for 3rd container If, for some reason, one of the PVCs is lost the above steps would have to be performed on the new container, post Helm install

If some of these files were configurable as configmaps, mounted in the correct filesystem, post install configuration could be avoided Additional capabilities, such as this, https://confluence.atlassian.com/jirakb/change-the-login-and-logout-urls-for-jira-server-433390329.html could be configured at deployment time (or preserved during helm updates)

Product

Jira

Code of Conduct

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

[bianchi2]

@mumbley I struggle to understand why you need to run Jira configuration tool after scaling (exec'ing into pod)? If local home pvc is lost for some reason, when a pod restarts, its local home will be re-populated. There's no need to do anything after scaling Jira to 2 or more replicas, other than wait until index replication finishes. And you can't add 2 or more replicas simultaneously - that's Jira limitation, so adding 1 replica at a time is the way to go.

[mumbley]

The reason I have to exec into the container after first startup (or after losing a PVC) is because of this https://github.com/atlassian/data-center-helm-charts/issues/457 which you have already replied to.

[bianchi2]

@mumbley I still don't quite get it. Yes, schema is missing and after the initial helm install you need to configure everything in the UI. After that, all you need to do is to scale statefulset. I don't see why exec is necessary at all.

As to losing PVC - which one do you refer to? Shared home which is RWX or a local home which is RWO? Yes, losing shared home is equivalent to losing your instance. Losing local home pvc will just cause issues with a node, and pod restart will re-populate that volume.

[bianchi2]

@mumbley you can create those configmaps yourself and use additionalFiles in values.yaml. The changes you suggest are not in the scope of just Helm deployment. When the initial configuration is completed, shared home PVC has some critical files, and this PVC needs to be backed up so that you can restore it in case it's lost.

You can create such configmaps outside Helm and mount them to your Jira container.

[bianchi2]

@mumbley I have just deployed jira to my test EKS cluster. The sequence was:

• deploy with shared home and local home PVCs and database properties in values.yaml
• once deployment is finished, complete installation in UI (set Jira home, provide license, create admin user)
• scale statefulset to 2

I struggle to understand why you have to exec into pods. I assume there's a misconfiguration issue or you have changed smth in the Helm chart.

[bianchi2]

@mumbley I'll be closing this issue. Feel free to reopen if you have more details