Current Upgrade plan
6.3.15->6.4.14->7.0.11->8.10

https://confluence.atlassian.com/adminjiraserver074/upgrading-jira-applications-using-the-installer-881683273.html?_ga=2.219711518.684639599.1593546483-821977391.1584022985#UpgradingJIRAapplicationsusingtheinstaller-1.Determineyourupgradepath

List of all Plugins
Atlassian Hipchat Integration Plugin
Atlassian Hipchat Integration Plugin Core
Atlassian JIRA - Plugins - Healthcheck Plugin UPDATE AVAILABLE
Atlassian Universal Plugin Manager Plugin UPDATE AVAILABLE
HipChat Core Plugin
HipChat for JIRA UPDATE AVAILABLE ->updated no error
JIRA Agile INCOMPATIBLE -> UPDATE AVAILABLE
JIRA Calendar Plugin
JIRA iCalendar Plugin UPDATE AVAILABLE ->updated no error

Updating the Atlassian Universal Plugin Manager Plugin breaks the overall jira upgrade, the reason being latest version of the plugin being incompatible with older JIRA version

[~aloraine] Please let me know if the Hipchat plugins are needed anymore

Mysql connector: https://repo1.maven.org/maven2/mysql/mysql-connector-java/8.0.20/mysql-connector-java-8.0.20.jar

JIRA 6.4.14 tar: https://product-downloads.atlassian.com/software/jira/downloads/atlassian-jira-6.4.14.tar.gz

Jira 6.4.14 to 7 upgrade gives the error listed below
https://confluence.atlassian.com/jirakb/logging-into-jira-server-returns-500-internal-server-error-781396615.html

2 plugins in our current installation are present in the cause list
hipchat-for-jira-plugin-6.31.0
jira-calendar-plugin-2.1.11

for safer approach, I have disabled all plugins during upgrade

Jira universal plugin manager repo: https://marketplace.atlassian.com/apps/23915/atlassian-universal-plugin-manager/version-history?_ga=2.191195619.878552869.1594095775-821977391.1584022985

Upgrade to 6.4.14 is sucessful with below observed issues
The plugin page refreshes automatically on expanding individual plugin management. Issue Highlighted in below link
https://community.atlassian.com/t5/Jira-Questions/Addons-page-reloads-after-click-in-quot-expand-quot-gt/qaq-p/989782?tempId=eyJvaWRjX2NvbnNlbnRfbGFuZ3VhZ2VfdmVyc2lvbiI6IjIuMCIsIm9pZGNfY29uc2VudF9ncmFudGVkX2F0IjoxNTk0MTI4NjI1NDE5fQ%3D%3D

This issue is fixed installing the newer version of the plugin in the path /home/ec2-user/jiradata/jira/jiraHome/plugins/installed-plugins

installed Universal Package Manager: 2.22.18.jar

https://marketplace-cdn.atlassian.com/files/artifact/6fc179a5-a587-4d1a-bc37-c22cfe3b705f/atlassian-universal-plugin-manager-plugin-2.22.18.jar

Licence information is lost post upgrade to 7.0.11 https://confluence.atlassian.com/jirakb/manage-jira-server-license-using-database-queries-441746313.html

[~aloraine]Could you please share with me the licence key information?

I have not found any general problems with the new jira board.

95% Jira deployment is automated

JIRA Upgrade deployment Strategy with the least downtime will be below.
1. We make a clone of existing Jira (no domain associated yet)
2. Upgrade the clone 6.3.15->6.4.14->7.0.11->8.10
3. Check if Clone functions well... Disassociate the existing domain and associate it to the new clone.
4. Stop running Jira on the old instance.

The New Jira 8.10 requires a Database version upgrade. And the OS which is currently in use on existing Jira needs a little tweaking(not difficult but manual addition to yum repo) to get the latest MySQL DB setup. I have to install rpm package instead of simple yum command.

[~aloraine] Please let me know your thoughts on the deployment strategy

This upgrade might also be a good time to install any new plugins and keep for future use. Plugins always seem to throw issues of compatibility, so if you have any specific plugin you want me to test out and install, please let me know.
[~aloraine]

JIRA upgrade playbook is ready and tested.

Please Review: https://bitbucket.org/chesterdias/jira-playbooks-chester-local/branch/IGBF-2461#diff

[~aloraine] Can you please provide me with the apache default-site.conf and ssl config files from the existing jira server

See google doc directory "Jira" for files ssl.conf and httpd.conf.

Added Code for setup of domain and ssl
Please Review: https://bitbucket.org/chesterdias/jira-playbooks-chester-local/branch/IGBF-2461#diff

General comment:

For this new instance of Jira, I would like to change the domain name to jira.bioviz.org instead of jira.transvar.org.

This is a pretty huge change because that link is repeated in many locations. But the address "jira.bioviz.org" is much better and easier to remember.

Good news is that this makes our migration process a bit easier.

Also, wherever possible, please use the "defaults" main.yml file within each role to provide reasonable defaults for as many variables as possible.

For example, use defaults to specify the Amazon availability zone – us east for us.

Some change and clarification requests:

group_vars/common.yml:

Comments:

• Comments explaining "upgrade_jira_version" suggest that the user can enter whatever version they want. I'm pretty sure this is not the case because the upgrade needs to happen in a sequence, as you discovered. Do please clarify in the comments what values are allowed. However, if you are finding you have to write a lot of text to explain it, don't. Instead, explain it in the top-level README.md file. (See end of this comment for more on that.)

• Explain what "UPM" plugin is. Spell out the acronym and provide a link if that clarifies things. Fix typo.

Functionality change request:

• I would like for the user to place the certificate files within a "files" directory of the httpd role, not the home directory of the control node ansible user. Modify httpd role accordingly and also update the comments in common.yml. I believe the copy command will (by default) look for files to copy from within that directory.
• Please change variable "current_jira_version" to "legacy_jira_version"

(The word "current" is confusing because it could mean the Jira version we are using right now or it could mean the highest Jira version currently available.)

example_secrets.yml:

• Clarify in README.md or here in the comments: Should these be the same passwords already used by the clone's MySQL database? It is not clear how the user is supposed to select these passwords.
• Remove the dummy fake passwords. At this point, the main user (me) understands how to configure an ansible variables file. But if I stupidly forget and just copy example_secrets.yml to secrets.yml, then the example passwords will be used and our site will become super easy to hack.

httpd role:

• Please do not put the apache configuration files into the ansible playbooks repository. Instead, please use ansible's file editing modules to modify the apache configuration files that are installed with apache. Maybe take a look at how the appstore playbooks are doing that.
• At this point, you should also look at Gerlinguy's ansible galaxy httpd role. Review the first few chapters of the book you got from us a few weeks ago.

General comment: I am uneasy about our version-controlling other application's configuration files that are managed by other people and could change without warning. Instead, when we install software that contains configuration files that need to be edited by us, we should use ansible to do the editing.

mysql role:

• There are two database names mentioned: bioviz_db_name and jira_db_name. Maybe this is a typo?
• The following comment looks wrong - the passwords are in the secrets.yml file:

- name: Create database user with name in /group_vars/common.yml and password mentioned in the /group_vars/common.yml with all database privileges

roles/upgrade_jira/files/check-java.sh:

This looks like something that copied from the Jira software package. It does not appear to be needed here. Please remove it if yes.

roles/upgrade_jira/tasks/main.yml:

This comment was a bit confusing to me:

+#  This script covers the standard steps for JIRA software upgrade 
+#  Changes to dbconfig.xml in the future can simply be added to the templates folder
+#  with the name dbconfig-{{ upgrade_jira_version }}.xml
+#  The playbooks will automatically pick any dbconfig found for the JIRA version.
+#

This makes it sound like if I want to upgrade a running Jira instance, I put a file named for the Jira instance in the "templates" folder? Is this meant to support future upgrades? I would just delete this comment altogether and instead edit the top-level README.md to contain this information.

In my view, the project-level README.md is a much better place to describe how the plays are meant to work.

So do please add more instructions to the top-level README.md file.

• Explain how the initial deployment of the clone should be done, using the "tarballs" with Jira home directory (from jira.transvar.org) and its mysqldump output - the SQL tarball.
• Then describe step-by-step how the upgrade to the latest version of Jira should be done on the clone.
• I recommend dividing these two tasks into two different "setup.yml" style playbooks to reside at the top-level of the project - "clone.yml" and then "upgrade.yml"

Will do the requested edits

Below Changes have been made.
group_vars/common.yml:
"current_jira_version" is Changed to "legacy_jira_version"
Comments added to explain UPM
example_secrets.yml:
All requested changes are made
httpd role:
I agree this should move to ansible rather then replace file method. Working on this to move this to ansible managed.
mysql role:
Typo corrections made

roles/upgrade_jira/files/check-java.sh.
This is needed to automatically start the earlier Jira version below 8.10.0 This was added as an incomplete feature in version 7+. So the Jira 7 setup did not check for presence of openjdk java rather it would only check oracle java and fail from starting JIRA 7 server. I had to pick up the correct script for JIRA 8.10 setup.
After our JIRA upgrade completion, we can remove this from our playbooks permanently. This step is only for our current scenario.

roles/upgrade_jira/tasks/main.yml:
dbconfig-{{ upgrade_jira_version }}.xml This change was added on observation that from JIRA version 6 to 8 there have been huge number of changes like DB version changes, setup config changes
The current playbooks are governed by flags that decide if we want to run them in upgrade mode or clone mode using flag called 'clone' can either be set to `yes` or a `no`.

Rest of the requested details including the steps for upgrade, I will add them to Readme.md

Cc: [~aloraine]

All requested changes have been made and comments added to Readme.md wherever clarification is needed
Please review: https://bitbucket.org/chesterdias/jira-playbooks-chester-local/branch/IGBF-2461#diff

[~aloraine] Ansible was not able to extract the new Jira home tar of 21 July. It threw an error saying unsupported zip-type in ansible. Could you please recreate the tar and upload it again.

See:

https://superuser.com/questions/852589/tar-archive-wont-unpack-path-contains

Try this.

I found a solution to our tar issue added it in the JIRA 8 testing ticket.

JIRA Runbook: https://docs.google.com/document/d/1s6udyUh3fVi0HTnoOnHgaEFaY2iVkn34QJNQ2qgLcvc/edit#heading=h.mms1arz2u6mk

Quick request:

• Please fix links on your fork so that they go to Jira (https://bitbucket.org/chesterdias/jira-playbooks-chester-local/commits/)

See: https://canvas.instructure.com/courses/1164217/pages/set-up-your-fork-fork-igb-add-jira-link-add-ssh-key

Also, please submit PR with the latest code.

Links are fixed
PR: https://bitbucket.org/lorainelab/jira-playbooks/pull-requests/2/igbf-2461/diff

Updated the httpd settings file for making it to work with confluence
Please review: https://bitbucket.org/chesterdias/jira-playbooks-chester-local/commits/78ff32f65e9aafc60d9bb99ff880302e9e1569b1?at=IGBF-2461

Pushed branch IGBF-2461 from git@bitbucket.org:chesterdias/jira-playbooks-chester-local.git.
Moving to Closed.