Re: No migration action required when going from 2.1.0 to 2.2.0 using pgsql backend

Hello Martin:

You have raised an interesting issue. AFAIK nobody has tested 2.2.0
with PostgreSQL 10.

In message <[email protected]>,
=?UTF-8?Q?Martin_=c3=96stlund?= via Roundup-users writes:
>I'm performing an upgrade from 2.1.0 to 2.2.0, using Postgresql 10.23 as 
>backend.

Roundup supports Postgres full text search with Postgres 11.0 and
newer. Version 10.23 should work fine for all other Roundup uses. Just
don't expect PostgreSQL FTS to work after the upgrade.

However I wonder if that's a clue. If the upgrade fails it should not
tel you there is no need to upgrade though.

From my reading of the Roundup code, a failure when setting up the FTS
migration should result in an exception that is reported to the user.

I just took a look through the full text search documentation for
PostgreSQL for 10.x releases. The SQL we execute as part of the schema
upgrade should be compatible with 10.x. IIRC (and I could be wrong)
the query and data loading part of FTS need the version 11.0+
requirement.

Also FYI version 10.23 isn't supported by PostgreSQL anymore. I don't
know if RedHat has a newer supported version of postgres.

>Reading the upgrade steps on 
>https://www.roundup-tracker.org/docs/upgrading.html#migrating-from-2-1-0-to-2-2-0, 
>I would expect there to be schema changes for "Rdbms version change from 
>6 to 7 (required)".
>
>These are the steps I've taken, and the outcome

Just to verify, the original version of Roundup you are upgrading this
time was 2.1.0.

This is *not* a 2.0 upgrade to 2.2.0 and you are at the 2.1.0 -> 2.2.0
step in the procedure. Correct?

>1. Downloaded and extracted roundup-2.2.0.tar.gz
>2. python3 setup.py install
>3. systemctl stop roundup

If you are using the inbound email interface, did you stop it as well?

>4. roundup-admin -i /path/to/tracker updateconfig newconfig.ini

Were there any changes between your original config.ini and newconfig.ini?

Does allowed_api_origins exist in your new config.ini? If so your
config.ini was generated with the 2.2.0 configuration.

If there were no changes or you are missing allowed_api_origins, it
sounds like something went wrong with the install. If you installed
2.1.0 and 2.2.0 in different places/virtual environments, are you
calling the 2.1.0 roundup-admin.

What version does:

  roundup-admin -i <tracker_home>

report?

>5. replaced /path/to/tracker/config.ini with newconfig.ini
>6. roundup-admin -i /path/to/tracker migrate
>
>Last step (6) outputs "No migration action required".
>I would expect to perform necessary schema changes at this step. Are my 
>expectations wrong or should it have performed migrations?

Your expectations are correct.

>Python 3.6.8
>REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 8"
>REDHAT_BUGZILLA_PRODUCT_VERSION=8.7

I don't run RedHat, but I expect it would works as you expect. Perhaps
somebody else runs RH or one of it's derivatives and knows of a reason
it wouldn't.

The migration code is checked by our tests. The roundup-admin
interface to the code is not. (I'll see if I can fix that.) To tell if
this is a bug in the roundup-admin code, we need to see if the
migration has been done.

If you are running postgresql on the same machine as Roundup, run the
following (replace rounduptest with the name of your Roundup db):

  sudo -u postgres psql rounduptest -c 'select schema from schema;'

It will dump a json blob. The first field should be version. What
version does it show? If the upgrade completed, it should show 7. If
you are still using the 2.1.0 schema it should show 6.

Also run:

   sudo -u postgres psql rounduptest -c "\d __words"

the size of the _words column should be 55. E.G.

                      Table "public.__words"
   Column  |         Type          | Collation | Nullable | Default
  ---------+-----------------------+-----------+----------+---------
   _word   | character varying(55) |           |          |

if your schema update completed. If it is at 30 (IIRC) you're still at
the 2.1.0 schema.

If you have a remote postgresql DB, you should be able to run the psql
command with '-U <user> -w ' using the user/password in your
config.ini.

Hope this helps.

Let us know what you find. Hopefully we can solve this easily.

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.