-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Assess various upgrades for continued application stability #1372
Comments
The immediate updates that affect the stability of the application through the end of the contract are Boto3, Django, Python, and PostgreSQL and PostGIS, as noted above. TL;DR The most immediate task is the Boto->Boto3 upgrade as this impacts our monthly deployment. Upgrade deployment dependency Boto to Boto3: This package is installed as part of a local virtual environment we create during the deployment process. Boto is no longer supported, we should upgrade to Boto3 and confirm no issues with deployments. As in Derek's notes above its only use is for Upgrade Django 3.2.13 to 4.2 and Python 3.6.9 to 3.8.18: We are currently using the last Django LTS version (3.2.13) which ends security support April 1,2024. We should upgrade to the next version, 4.2, which we will not be able to do until we upgrade Python to 3.8.18. We should upgrade to 3.12 to give us maximum runway, see slack discussion. Upgrading Python is covered in 1356 and a separate task is created for upgrading Django. Even though it is a major version change some depreciation warnings have already been addressed in previous work,1320 , but we should still anticipate running into issues with our As part of this task we will also need to upgrade Upgrade PostgreSQL 12.7 to 14 and PostGIS 3.0 to 3.1:
The last PostgreSQL update was completed by first testing on develop and then running updates on the Production database. See step-by-step here. There shouldn't be difficulties between versions given the last few PostgreSQL upgrades and available documentation. However, we have limited developer familiarity with production database updates, last run 2 yeas ago, and at one point our development environment had gotten out of sync with our RDS environment (though this should have been addressed in last update). In addition, we are upgrading Python versions, psycopg2, and PostGIS in other tasks. Given scope of upgrades and a potential lack of parity and familiarity, a temporary staging database made from a duplicate of production to run upgrades would lower risk and production downtime. To upgrade PostgreSQL, if not creating a separate staging db for testing, follow instructions from last upgrade here. PostgreSQL 14 has community and Amazon RDS support through 2026 and we will need to upgrade PostGIS to 3.1 to support. In the last few PostgreSQL upgrades there have been few difficulties and similarly for PostGIS because this is a minor upgrade and the last one did not have difficulties we can expect limited issues. In past upgrade we estimated ~2 hours of production database downtime. |
Closing this issue after updating task list with recommendations from slack discussion. |
We need to run various upgrades spring 2024 to support application stability through the end of the contract. We should generate a task list of the different upgrades, their priority levels and effort estimates. Of note, from Derek:
The text was updated successfully, but these errors were encountered: