site-upgrade from 1.7.14 to 2.0.20 fails

[Martin Großhauser]

I'm trying to upgrade ReviewBoard to 2.0.20, but site-upgrade fails with output:

# rb-site upgrade /var/www/reviewboard
Rebuilding directory structure
Updating database. This may take a while.

The log output below, including warnings and errors,
can be ignored unless upgrade fails.

------------------ <begin log output> ------------------
Creating tables ...
Upgrading Review Board from 1.7.14 to 2.0.20
There are unapplied evolutions for auth.
There are unapplied evolutions for contenttypes.
There are unapplied evolutions for accounts.
There are unapplied evolutions for attachments.
There are unapplied evolutions for changedescs.
There are unapplied evolutions for diffviewer.
There are unapplied evolutions for hostingsvcs.
There are unapplied evolutions for reviews.
There are unapplied evolutions for scmtools.
There are unapplied evolutions for site.
Project signature has changed - an evolution is required
Installing custom SQL ...
Installing indexes ...
Installed 0 object(s) from 0 fixture(s)
The stored evolutions do not completely resolve all model changes.

Run `./manage.py evolve --hint` to see a suggestion for the changes required.

The following are the changes that could not be resolved:
The application markup has been deleted
In model attachments.FileAttachment:
    In field 'file':
        Property 'max_length' has changed
In model hostingsvcs.HostingServiceAccount:
    Field 'hosting_url' has been added
The model auth.Message has been deleted
In model reviews.FileAttachmentComment:
    Field 'extra_data' has been added
In model reviews.ReviewRequest:
    Field 'depends_on' has been added
In model reviews.ReviewRequestDraft:
    Field 'depends_on' has been added
In model accounts.Profile:
    Field 'timezone' has been added
    Field 'open_an_issue' has been added
    Field 'extra_data' has been added
In model diffviewer.DiffSet:
    Field 'base_commit_id' has been added
In model diffviewer.DiffSetHistory:
    Field 'last_diff_updated' has been added
In model diffviewer.FileDiff:
    Field 'diff_hash' has been added
    Field 'parent_diff_hash' has been added
    Field 'diff64' has been added
    Field 'parent_diff64' has been added
    Field 'parent_diff' has been deleted
    Field 'diff' has been deleted
CommandError: Your models contain changes that Django Evolution cannot resolve automatically.

OS-Version is:
CentOS release 6.7 (Final)

Django packages are:
# yum list installed |grep -i django
Django14.noarch                     1.4.21-1.el6                       @epel
python-django-evolution.noarch      1:0.6.9-4.el6                      @epel

python-django-pipeline.noarch       1.2.24-2.el6                       @epel

Do you have any idea what's going wrong here? I'm grateful for any ideas how to solve this problem.

Extra question: I expected an upgrade to version 3. Instead I got 2.0.20. Why is that?

Kind regards,
Martin

[Stephen Gallagher]

I maintain the packages for EPEL. ReviewBoard is abandoned on EPEL 6
because versions newer than 2.0 are incompatible with the set of
packages available in RHEL 6. If you want to go to 3.x and use the RPM
packages, you need to be on RHEL 7.

Otherwise, you need to go the pip route, but I'm not sure that will
work with the extremely old version of python on RHEL 6.

[Martin Großhauser]

Thanks for your reply.

Indeed, there was version 1.7.27 from EPEL installed. But the version running according to the web interface was 1.7.14. Also in the SQL-table siteconfig_siteconfiguration I see a string '1.7.14', which looks to me like the version. Uninstalling the RPM version and reinstalling 2.0.20 via easy_install with an rb-site upgrade afterwards did not resolve my issue.

Maybe there is a version conflict in the current setup?

I did not maintain this setup in the past, so I do not know much about what happened before. Internal documentation shows there was at least an unfinished upgrade to 1.7.27 with an inconsistent state in between. Version was rolled back to 1.7.14 then, but maybe some artifacts remained, which are causing the current trouble.

[Eric Johnson]

On Monday, June 3, 2019 at 7:58:29 AM UTC-7, Martin Großhauser wrote:

Thanks for your reply.

Indeed, there was version 1.7.27 from EPEL installed. But the version running according to the web interface was 1.7.14. Also in the SQL-table siteconfig_siteconfiguration I see a string '1.7.14', which looks to me like the version. Uninstalling the RPM version and reinstalling 2.0.20 via easy_install with an rb-site upgrade afterwards did not resolve my issue.

Maybe there is a version conflict in the current setup?

I did not maintain this setup in the past, so I do not know much about what happened before. Internal documentation shows there was at least an unfinished upgrade to 1.7.27 with an inconsistent state in between. Version was rolled back to 1.7.14 then, but maybe some artifacts remained, which are causing the current trouble.

Oh, this is a critical detail. There are two paths that I can think of here.

Path 1) Install a fresh copy of your current installed version (1.7.14) into a fresh database, and compare that database schema to the one for your production install. If they differ, repeat the exercise with 1.7.27, and see how that differs. It may be that you've got most of the changes for 1.7.27, but for a few, and might be able to apply those.

At one point in the distant past of our ReviewBoard use (1.X), I did run into problems with a mismatch between the database layout and the version of ReviewBoard. It had to do with a similar situation - an aborted upgrade. I thought I had rolled back. In the end, I had to manually bring the database forward to the expected version. Once I did that, I haven't had problems since. However, I've been a die-hard developer for a long time, this path might not be for you. Digging into SQL, and pouring over the Python code of RB didn't deter me (it is pretty good code, as open source goes. It is almost like each commit gets reviewed ;-) ).

Path 2) ReviewBoard is a great tool, and BeanBag deserves $$ for the work they do making it. Perhaps pay for support from the company help untangle the issue you've got? It may save you a lot of time, and be worth every dollar spent.

Eric.

[Martin Großhauser]

Hi Eric,

thanks for your reply. As it was not top priority to migrate all the old data to the new version I installed a fresh, empty 3.0 instance and restored the old 1.7 instance to an at least working state for archive purposes.

Kind regards,

Martin