This Bug Report affects these Traffic Control components:
Current behavior:
We have no mechanism to verify that multiple Traffic Ops instances are not trying to run the TO Postinstall at the same time.
Previously filed in #4984; sort of fixed in #5138 by making create_tables.sql alone idempotent; idempotency is lost as soon as squash_migrations.sh from #6096 is used.
Expected behavior:
When the Postinstall script starts, it should check if a postinstall lock exists in the DB, and if so, wait for it to be cleared. If there is no lock, it should set one and clear it once Postinstall completes (with or without an error).
The cdn_lock table cannot be used because the username and cdn_name are non-nullable foreign keys.
Also, we should be using --single-transaction for all of our psql commands in the Postinstall script and in db/admin.
Steps to reproduce:
Try to run the Traffic Ops Postinstall on the same database from two separate TO instances at the same time.
This Bug Report affects these Traffic Control components:
Current behavior:
We have no mechanism to verify that multiple Traffic Ops instances are not trying to run the TO Postinstall at the same time.
Previously filed in #4984; sort of fixed in #5138 by making
create_tables.sqlalone idempotent; idempotency is lost as soon assquash_migrations.shfrom #6096 is used.Expected behavior:
When the Postinstall script starts, it should check if a postinstall lock exists in the DB, and if so, wait for it to be cleared. If there is no lock, it should set one and clear it once Postinstall completes (with or without an error).
The
cdn_locktable cannot be used because theusernameandcdn_nameare non-nullable foreign keys.Also, we should be using
--single-transactionfor all of ourpsqlcommands in the Postinstall script and indb/admin.Steps to reproduce:
Try to run the Traffic Ops Postinstall on the same database from two separate TO instances at the same time.