Bug #29429

Dynflow tables are tried to migrate in parallel
Pull request:
Fixed in Releases:
Found in Releases:
Description
Suspision: dynflow tries to migrate the tables when it boots up. Maybe dynflow tries to migrate the db several times at once from different puma workers
Examples:
- CentOS 7:
/opt/theforeman/tfm/root/usr/share/gems/gems/sequel-5.7.1/lib/sequel/adapters/postgres.rb:146:in `async_exec': PG::UniqueViolation: ERROR: duplicate key value violates unique constraint "pg_type_typname_nsp_index" (Sequel::UniqueConstraintViolation) DETAIL: Key (typname, typnamespace)=(dynflow_schema_info, 2200) already exists.
- Ubuntu 18.04:
dynflow-sidekiq@orchestrator[8451]: More than 1 row in migrator table dynflow-sidekiq@orchestrator[8451]: /usr/share/foreman/vendor/ruby/2.5.0/gems/sequel-5.30.0/lib/sequel/extensions/migration.rb:620:in `schema_dataset' dynflow-sidekiq@orchestrator[8451]: /usr/share/foreman/vendor/ruby/2.5.0/gems/sequel-5.30.0/lib/sequel/extensions/migration.rb:455:in `initialize' dynflow-sidekiq@orchestrator[8451]: /usr/share/foreman/vendor/ruby/2.5.0/gems/sequel-5.30.0/lib/sequel/extensions/migration.rb:519:in `initialize' dynflow-sidekiq@orchestrator[8451]: /usr/share/foreman/vendor/ruby/2.5.0/gems/sequel-5.30.0/lib/sequel/extensions/migration.rb:402:in `new' dynflow-sidekiq@orchestrator[8451]: /usr/share/foreman/vendor/ruby/2.5.0/gems/sequel-5.30.0/lib/sequel/extensions/migration.rb:402:in `run' dynflow-sidekiq@orchestrator[8451]: /usr/share/foreman/vendor/ruby/2.5.0/gems/dynflow-1.4.3/lib/dynflow/persistence_adapters/sequel.rb:263:in `migrate_db'
Associated revisions
Fixes #29429 - Bump dependency on Dynflow
History
#1
Updated by Ewoud Kohl van Wijngaarden over 2 years ago
One solution is to create rake tasks to do this and let the installer handle it. For the regular DB it uses two tasks (db:migrate and db:abort_if_pending_migrations) to indicate whether a migration is needed and to actually migrate. This provides idempotency.
#2
Updated by The Foreman Bot over 2 years ago
- Assignee set to Adam Ruzicka
- Status changed from New to Ready For Testing
- Pull request https://github.com/theforeman/foreman/pull/7593 added
#3
Updated by Adam Ruzicka over 2 years ago
- Category deleted (
DB migrations) - Pull request https://github.com/Dynflow/dynflow/pull/353 added
#4
Updated by The Foreman Bot about 2 years ago
- Fixed in Releases 2.2.0 added
#5
Updated by Adam Ruzicka about 2 years ago
- Status changed from Ready For Testing to Closed
Applied in changeset 7a3d995cc2fe6e84ad25f487476e39dc0ed96415.
#6
Updated by Tomer Brisker about 2 years ago
- Fixed in Releases 2.1.0 added
- Fixed in Releases deleted (
2.2.0)
#7
Updated by Amit Upadhye about 2 years ago
- Category set to DB migrations
Fixes #29429 - Provide rake tasks for Dynflow migrations
Historically Dynflow tried to migrate its database on startup. This became an
issue with the move to Puma, because multiple instance of Dynflow running in
separate Puma workers would try to migrate the database concurrently and the
workers would die because of unique key validation errors.
This change adds dynflow:abort_if_pending migrations rake task for checking if
the Dynflow database is fully migrated. It also extends the db:migrate and
db:abort_if_pending_migrations to run their Dynflow counterparts as well.