Hi ATC, All good things eventually come to an end, but so does Goose. I have a PR out there that gets us using Migrate < https://github.com/golang-migrate/migrate> instead of Goose: https://github.com/apache/trafficcontrol/pull/6057
The big improvement is that Migrate is compiled into `db/admin` as a library. It does not need to be installed after installing Traffic Ops, you already have it because the Traffic Ops RPM includes the `db/admin` tool. Benefits of this: • Traffic Ops no longer requires an Internet connection to run `postinstall` script. • Golang has been removed as a dependency from Traffic Ops. Although it was not listed in the RPM spec, building Goose also required Git, which is also no longer needed. • Goose required CGO, which precluded building a Traffic Ops RPM targeting x86_64 Linux from other platforms like macOS and Windows if we ever ended up including the `goose` binary in the Traffic Ops RPM. This is no longer an issue. Compatibility features: • The database config file stays the same, you can keep using your existing `dbconf.yml` as-is. • With the exception of `db/admin status`, all `db/admin` commands work like they used to (`db/admin status` explained below in the Differences section). For example, the command to run the migrations is still `db/admin -env production migrate`. • Although the "up" and "down" migrations are split into separate files now, the contents of each existing migration are otherwise unmodified, other than removing Goose annotations like `+goose Up` and `+goose StatementBegin`. • No extra migration steps should be necessary, you can run `db/admin -env production migrate` to migrate from Goose (which uses the `goose_db_version` table) to Migrate (which uses the `schema_migrations` table), meaning that Migrate will start at the migration version that Goose used. The `goose_db_version` table is renamed to `goose_db_version_unused` to preserve the Goose migration history while ensuring that only Migrate is used going forward. If for any reason you do want to go back to Goose, you can run the `00000000000000_init.down.sql` migration to rename the Goose table back to `goose_db_version`, so this is a non-destructive change. • The `install_goose.sh` script still exists in the repo, it just does not do anything. It will be removed in a future ATC release. As a new feature, you can now create migrations directly from `db/admin` using `db_admin create_migration NAME`. Migrations created this way have 16-digit timestamps (as opposed to the 14-digit timestamps that `goose create` produced) and contain the Apache License 2.0. Differences: • Migrate keeps track of the migration version and "dirty" status (true or false) in the `schema_migrations` table. If "dirty" is `true`, that means that the last migration to run failed. If it is set, the "dirty" flag needs to be cleared manually. • Other than storing the version of the last migration to have run, Migrate does *not* keep track of which migrations in the past have run. If a new migration is created with a timestamp before the current migration version, Migrate will ignore that migration. • `db/admin status` is now an alias for `db/admin dbversion`. This is because `db/admin status` was a wrapper for `goose status`, which printed the status of each migration. `db/admin status` has been deprecated, pending removal in a future ATC release. • Because each "up" migration and its corresponding "down" migration are split into separate files, and because there are no longer any Goose annotations, Goose cannot use the new Migrate migrations. That's it! Thoughts and suggestions are welcome both in the PR and here on the mailing list. -Zach
