[Pulp-list] Pulp migration order

Rohan McGovern rmcgover at redhat.com
Wed Oct 19 03:26:15 UTC 2016


We're working on some custom Pulp migrations to fix up some data issues
in our Pulp installation.
https://docs.pulpproject.org/dev-guide/newtypesupport/plugin/migrations.html

The migration mechanism has an annoying restriction: there aren't
allowed to be any gaps in the migration sequence.  For example, if I
have 0001_my_first_migration.py and 0003_add_email_addresses_to_users.py
then pulp-manage-db won't run migration 3 due to the absence of a
migration numbered 2.

There is a good reason for it not to work this way: this means that the
next number in the sequence is in contention between all separately
developed patches which might need to add migrations.  For example, if
there are currently migrations 1-3, multiple developers working on new
migrations concurrently are all forced to use number 4 (otherwise their
code won't run) but in the end, only one of them can "win" and all the
others will have to renumber theirs later.  If the migrations are
independent from each other, that's wasted time.

Compare with e.g. ActiveRecord where migrations are "numbered" by
timestamp at time of generation, and there's no problem merging branches
where unrelated migrations were authored separately.
http://guides.rubyonrails.org/active_record_migrations.html

Is there a particular reason for the current pulp migration system to
work this way?




More information about the Pulp-list mailing list