Uploaded image for project: 'IGB'
  1. IGB
  2. IGBF-2461

Upgrade Jira clone and document the process

    Details

    • Type: Task
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Story Points:
      3.5
    • Sprint:
      Summer 3: 6 Jul - 17 Jul, Summer 4: 14 Jul - 28 Jul, Summer 5: 3 Aug - 14 Aug, Summer 6: 17 Aug - 28 Aug, Summer 7: 31 Aug - 11 Sep, Fall 1: 14 Sep - 25 Sep, Fall 2: 28 Sep - 9 Oct, Fall 3: Oct 12 - Oct 23

      Description

      See: https://community.atlassian.com/t5/Jira-Software-questions/Upgrade-to-Jira-v8-9-1-from-v6-3-15/qaq-p/1411742

      from: Nic Brough Adaptavist COMMUNITY LEADER Jun 21, 2020

      See https://confluence.atlassian.com/adminjiraserver/upgrading-jira-applications-938846936.html

      Bear in mind that you need to go through several versions. The recommended upgrade path is 6.3 -> 6.4 -> 7.0 -> 7.13 -> 8.9

      You might be able to skip 6.4 but under no circumstances skip 7.0. If you skip it, it will corrupt certain bits of data which then breaks new functions that arrive in 7.8ish and above.

        Attachments

          Issue Links

            Activity

            Show
            cdias1 Chester Dias (Inactive) added a comment - 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
            Hide
            cdias1 Chester Dias (Inactive) added a comment - - edited

            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

            Show
            cdias1 Chester Dias (Inactive) added a comment - - edited 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
            Show
            cdias1 Chester Dias (Inactive) added a comment - Mysql connector: https://repo1.maven.org/maven2/mysql/mysql-connector-java/8.0.20/mysql-connector-java-8.0.20.jar
            Show
            cdias1 Chester Dias (Inactive) added a comment - JIRA 6.4.14 tar: https://product-downloads.atlassian.com/software/jira/downloads/atlassian-jira-6.4.14.tar.gz
            Hide
            cdias1 Chester Dias (Inactive) added a comment -

            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

            Show
            cdias1 Chester Dias (Inactive) added a comment - 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
            Show
            cdias1 Chester Dias (Inactive) added a comment - Jira universal plugin manager repo: https://marketplace.atlassian.com/apps/23915/atlassian-universal-plugin-manager/version-history?_ga=2.191195619.878552869.1594095775-821977391.1584022985
            Hide
            cdias1 Chester Dias (Inactive) added a comment -

            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

            Show
            cdias1 Chester Dias (Inactive) added a comment - 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
            Hide
            cdias1 Chester Dias (Inactive) added a comment - - edited

            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

            Show
            cdias1 Chester Dias (Inactive) added a comment - - edited 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
            Show
            cdias1 Chester Dias (Inactive) added a comment - Licence information is lost post upgrade to 7.0.11 https://confluence.atlassian.com/jirakb/manage-jira-server-license-using-database-queries-441746313.html
            Hide
            cdias1 Chester Dias (Inactive) added a comment -

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

            Show
            cdias1 Chester Dias (Inactive) added a comment - [~aloraine] Could you please share with me the licence key information?
            Hide
            nfreese Nowlan Freese added a comment -

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

            Show
            nfreese Nowlan Freese added a comment - I have not found any general problems with the new jira board.
            Hide
            cdias1 Chester Dias (Inactive) added a comment -

            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

            Show
            cdias1 Chester Dias (Inactive) added a comment - 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
            Hide
            cdias1 Chester Dias (Inactive) added a comment -

            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]

            Show
            cdias1 Chester Dias (Inactive) added a comment - 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]
            Hide
            cdias1 Chester Dias (Inactive) added a comment -

            JIRA upgrade playbook is ready and tested.

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

            Show
            cdias1 Chester Dias (Inactive) added a comment - JIRA upgrade playbook is ready and tested. Please Review: https://bitbucket.org/chesterdias/jira-playbooks-chester-local/branch/IGBF-2461#diff
            Hide
            cdias1 Chester Dias (Inactive) added a comment -

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

            Show
            cdias1 Chester Dias (Inactive) added a comment - [~aloraine] Can you please provide me with the apache default-site.conf and ssl config files from the existing jira server
            Hide
            ann.loraine Ann Loraine added a comment -

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

            Show
            ann.loraine Ann Loraine added a comment - See google doc directory "Jira" for files ssl.conf and httpd.conf.
            Hide
            cdias1 Chester Dias (Inactive) added a comment -
            Show
            cdias1 Chester Dias (Inactive) added a comment - Added Code for setup of domain and ssl Please Review: https://bitbucket.org/chesterdias/jira-playbooks-chester-local/branch/IGBF-2461#diff
            Hide
            ann.loraine Ann Loraine added a comment - - edited

            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"
            Show
            ann.loraine Ann Loraine added a comment - - edited 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"
            Hide
            cdias1 Chester Dias (Inactive) added a comment -

            Will do the requested edits

            Show
            cdias1 Chester Dias (Inactive) added a comment - Will do the requested edits
            Hide
            cdias1 Chester Dias (Inactive) added a comment -

            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]

            Show
            cdias1 Chester Dias (Inactive) added a comment - 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]
            Hide
            cdias1 Chester Dias (Inactive) added a comment -

            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.

            Show
            cdias1 Chester Dias (Inactive) added a comment - 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.
            Show
            ann.loraine Ann Loraine added a comment - See: https://superuser.com/questions/852589/tar-archive-wont-unpack-path-contains Try this.
            Hide
            cdias1 Chester Dias (Inactive) added a comment -

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

            Show
            cdias1 Chester Dias (Inactive) added a comment - I found a solution to our tar issue added it in the JIRA 8 testing ticket.
            Show
            cdias1 Chester Dias (Inactive) added a comment - JIRA Runbook: https://docs.google.com/document/d/1s6udyUh3fVi0HTnoOnHgaEFaY2iVkn34QJNQ2qgLcvc/edit#heading=h.mms1arz2u6mk
            Hide
            ann.loraine Ann Loraine added a comment -

            Quick request:

            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.

            Show
            ann.loraine Ann Loraine added a comment - 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.
            Show
            cdias1 Chester Dias (Inactive) added a comment - Links are fixed PR: https://bitbucket.org/lorainelab/jira-playbooks/pull-requests/2/igbf-2461/diff
            Hide
            cdias1 Chester Dias (Inactive) added a comment -

            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

            Show
            cdias1 Chester Dias (Inactive) added a comment - 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
            Hide
            ann.loraine Ann Loraine added a comment -

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

            Show
            ann.loraine Ann Loraine added a comment - Pushed branch IGBF-2461 from git@bitbucket.org:chesterdias/jira-playbooks-chester-local.git. Moving to Closed.

              People

              • Assignee:
                cdias1 Chester Dias (Inactive)
                Reporter:
                ann.loraine Ann Loraine
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: