No module named 'requests' (Upgrading pre v1.0.0 version help)

[terranova-joseph]

We have a very old Redash instance version 0.12.0+b2449 and I am following the upgrade instructions https://redash.io/help/open-source/admin-guide/how-to-upgrade-legacy. Following the "How to upgrade (pre v1.0.0 versions)" after I run sudo ./upgrade i receive the following error:

Traceback (most recent call last):
  File "./upgrade", line 10, in <module>
    import requests
ImportError: No module named 'requests'

I am hoping to upgrade this instance all the way up to version 10. The thing I am most concerned about is the database schema. The database is running on it's own RDS instance. Would I upgrade manually to a certain version, then build a new Redash instance using the AWS EC2 AMI so that I'm running using Docker, then upgrade to version 10? Any recommendations you have will be appreciated!

[arikfr]

Considering that you have your database on its own RDS instance, I would suggest starting a new instance with a Docker based deployment of Redash. This will make upgrades in the future much simpler.

The outline of the upgrade would be --

1. Start a new instance with a Docker based deployment.
2. Change the configuration not to run a local Postgres database and configure the connection string to connect to your RDS instance.
3. Run migrations.

Of course I suggest making a backup of the database before running migrations.

[terranova-joseph]

Hi @arikfr,

This approach makes a lot of sense.

I have a new Docker-based instance up and running with the latest version of Redash.

I changed the config to point to the legacy Redash database running on RDS.

On the new instance, I execute the following:

$ docker-compose run --rm server manage db upgrade
Starting redash_redis_1    ... done
Starting redash_postgres_1 ... done
[2023-03-28 16:05:30,543][PID:1][INFO][alembic.runtime.migration] Context impl PostgresqlImpl.
[2023-03-28 16:05:30,543][PID:1][INFO][alembic.runtime.migration] Will assume transactional DDL.
[2023-03-28 16:05:30,605][PID:1][INFO][alembic.runtime.migration] Running upgrade  -> 65fc9ede4746, Add is_draft status to queries and dashboards
[2023-03-28 16:05:30,706][PID:1][INFO][alembic.runtime.migration] Running upgrade 65fc9ede4746 -> d1eae8b9893e, add Query.schedule_failures
[2023-03-28 16:05:30,711][PID:1][INFO][alembic.runtime.migration] Running upgrade d1eae8b9893e -> 7671dca4e604, empty message
[2023-03-28 16:05:30,715][PID:1][INFO][alembic.runtime.migration] Running upgrade 7671dca4e604 -> 5ec5c84ba61e, Add Query.search_vector field for full text search.
[2023-03-28 16:05:31,549][PID:1][INFO][alembic.runtime.migration] Running upgrade 5ec5c84ba61e -> 6b5be7e0a0ef, Re-index Query.search_vector with existing queries.
[2023-03-28 16:05:32,097][PID:1][INFO][alembic.runtime.migration] Running upgrade 6b5be7e0a0ef -> 969126bd800f, Update widget's position data based on dashboard layout.
Updating dashboards position data:

I've let this run for more than 15 minutes, and unfortunately the migration just hangs at this point. Any ideas why this might be happening?

[arikfr]

There might be some database lock? You can check for running queries by querying pg_stat_activity.