Discourse v3.0.6 to v3.1.1 upgrade error - undefined method `register_bookmarkable' for Bookmark:Class

installation
21

Have you tried a new install with no restore but connecting to your existing backend database?

I guess that means potentially losing any settings made in the UI not persisted to the database? Am not sure what else is backed up and restored though.

22

Maybe you should consider moving away from bitnami to an actual standard install. Your problems are not caused by ā€œbugs in the database migrationā€, they are bitnami specific.

2 Likes
23

Is there a standard install for Kubernetes yet?

24

Does Kubernetes allow you to do a manual install? If so, you could do a standard install that way. (Iā€™ve never tried it, so I donā€™t know how Kubernetes works)

25

I hear you loud and clear about the advantages of the standard install and the independent and unsanctioned nature of the Bitnami Helm chart. I did not intend to insinuate that the fault lies with Discourse itself. My choice to use Bitnami continues to depend on a calculation comparing the cost of troubleshooting issues with the Bitnami chart and the cost of developing my own equivalent Helm chart based on the officially supported installation and then troubleshooting issues with it.

I considered it, but I am trying to avoid modifications to the default chart settings to stay ā€œon the main pathā€. That being said, I did attempt to upgrade only the Discourse server to v3.2.0 by overriding the Deployment image tag, while retaining the existing database, to see if the migration would succeed; it still failed.

I have tried to manually drop and restore the database via kubectl exec to the postgres container using the SQL dump file generated by Discourse itself, but this fails with the error about the sidebar_sections table. Most recently, I created a new VM and followed the standard install method to install Discourse v3.3.0. When I attempted a backup restore the same error occurred.

My conclusion is that, although the production backup archive was generated by Discourse itself, the database structure of my production instance v3.0.6 is somehow different from what Discourse expects, causing the migrations to error. If this is the case, I am pessimistic about my options. The only idea I have at the moment is to start hacking at the SQL dump file in the backup archive to remove tables causing the DuplicateTable errors that the db migration stage of the restore process.

26

If you want to use Bitnamiā€™s Helm Charts then you need to use their support.

1 Like
27

In the hopes that this will save someone from floundering for as many hours as I did in this predicament, here is the process that finally allowed me to upgrade from Discourse v3.0.6 to v3.2.0 in the context of using Bitnami Helm chart (v11 to v12). While further disclaimers should not be necessary based on comments above, this problem is due to a bug in Bitnamiā€™s Helm chart and their custom images; the problem does not affect official Discourse releases.

The instructions below show how to navigate the upgrade. The ā€œproduction siteā€ is a Helm chart release of the Discourse site being upgraded, and ā€œmigration siteā€ refers to a temporary chart release deployed in parallel in namespace discourse-dev.

Production site

  1. Set production forum to read-only mode in Backups admin panel /admin/backups.
  2. Make backup using Backups admin panel. Download backup archive locally.

Migration site

  1. Install fresh instance of Bitnami chart v12.6.2 (Discourse v3.2.0). Scale the Discourse server Deployment to zero.

    $ kubectl scale -n discourse-dev deployment discourse --replicas 0
deployment.apps/discourse scaled

  2. Create SQL file db_init.sql:

    cat > /tmp/db_init.sql << EOF
DROP DATABASE bitnami_application;
CREATE DATABASE bitnami_application;
GRANT ALL PRIVILEGES ON DATABASE bitnami_application TO bn_discourse;
CREATE EXTENSION hstore;
CREATE EXTENSION pg_trgm;
ALTER database bitnami_application owner to bn_discourse ;
EOF

  3. Copy to the database pod and execute:

    $ kubectl cp -n discourse-dev db_init.sql discourse-dev-postgresql-0:/tmp/

$ kubectl exec -n discourse-dev -it discourse-dev-postgresql-0 -- bash -c \
    'PGPASSWORD=$POSTGRES_PASSWORD psql -U postgres \
     < /tmp/db_init.sql'
DROP DATABASE
CREATE DATABASE
GRANT
ERROR:  extension "hstore" already exists
ERROR:  extension "pg_trgm" already exists
ALTER DATABASE

  4. Extract backup archive, copy SQL dump file to database pod, and apply:

    $ ls
discourse-2024-03-04-143102-v20230119094939.tar.gz
$ tar xvf discourse-2024-03-04-143102-v20230119094939.tar.gz 
$ gunzip dump.sql.gz 
$ kubectl cp -n discourse-dev dump.sql discourse-dev-postgresql-0:/tmp/
$ kubectl exec -n discourse-dev -it discourse-dev-postgresql-0 -- bash -c \
    'PGPASSWORD=$POSTGRES_PASSWORD psql -U bn_discourse \
     --dbname bitnami_application \
     < /tmp/dump.sql'

  5. Launch Discourse pod.

    $ kubectl scale -n discourse-dev deployment discourse --replicas 1
deployment.apps/discourse scaled

  6. Watch logs and drop tables that are preventing the upgrade:

    $ kubectl logs --prefix -f -n discourse-dev -c discourse -l app.kubernetes.io/name=discourse
$ kubectl logs --prefix -f -n discourse-dev -l app.kubernetes.io/name=postgresql

  7. Watch while db migrations fail and manually delete the relevant tables until migrations succeed:

    $ kubectl exec -n discourse-dev -it discourse-dev-postgresql-0 -- bash -c \
    'PGPASSWORD=$POSTGRES_PASSWORD psql -U bn_discourse --dbname bitnami_application -c "\
    DROP TABLE sidebar_sections; \
    DROP TABLE sidebar_urls; \
    DROP TABLE chat_threads; \
    DROP TABLE form_templates; \
    DROP TABLE category_settings; \
    DROP TABLE category_form_templates; \
    DROP TABLE theme_svg_sprites; \
    DROP TABLE user_chat_thread_memberships; \
    DROP TABLE summary_sections; \
    "'

  8. Restore uploads folder backup:

    $ PODNAME=$(kubectl get pod -n discourse-dev -l app.kubernetes.io/name=discourse --output=jsonpath={.items..metadata.name} | cut -f1 -d' ')
$ kubectl cp -n discourse-dev -c discourse uploads $PODNAME:/bitnami/discourse/public/
$ kubectl exec -n discourse-dev -c discourse $PODNAME -- bash -c 'chown -R 999:0 /bitnami/discourse/public/uploads/'

  9. For some reason, the plugins did not automatically download and install. Do this manually and verify plugin functionality.

    root@discourse-54c6d6fb7c-z9285:/bitnami/discourse/plugins$ git clone https://github.com/discourse/discourse-oauth2-basic
root@discourse-54c6d6fb7c-z9285:/bitnami/discourse/plugins$ git clone https://github.com/discourse/discourse-math
root@discourse-54c6d6fb7c-z9285:/bitnami/discourse/plugins$ chown -R 999:0 discourse-oauth2-basic discourse-math

  10. Create a backup of the newly restored site using Backups admin panel.

Production site

  1. Delete the original deployment and purge PV/PVCs.
  2. Install fresh instance of Bitnami chart v12.6.2 (Discourse v3.2.0).
  3. Use https://$BASE_URL/u/admin-login to login by email link.
  4. Upload and restore backup archive using Backups admin panel.
1 Like