While upgrading 3scale, in order to run System data migrations involving DML sequences, that are not implemented as Rails timestamped migration files (and neither they should!), we need to define an automated solution to hook those migrations into system's rollout process with no need of manual interaction of the user.

As sometimes such migrations are considered requirements of the new version, the solution should take that into account and prevent the application from being completely rolled out until the process finishes.

It should be analogous to what happens for DDL migrations, executed by system-app-pre-hook, although not necessarily using the same structures.

This data migration solution must work both for deployments based on Openshift templates or 3scale operator.

Talk to msorianod about this so that workaround from THREESCALE-3722 can be removed.

Dev note

A couple important guidelines to take into account about DML and DDL migrations:

• Data migrations (DML) are code and must be tested!
• No DML code should ever run before any DDL code within the same upgrade/deploy!

Making the point: We CANNOT allow, within the same on-prem version upgrade/Saas deploy, a migration sequence as follow:

1. ddl-1
2. dml
3. ddl-2 (DDL code that breaks dml)

And the reason is…

Assuming dml is tested, by the time we code ddl-2, we will break and of course “fix” dml. However, dml might still fail in the migration sequence above because it would run after ddl-1, yet "fixed" expecting ddl-2 to exist, though before ddl-2 itself runs.

It's all about dependency. So we don't need to keep tracking complex DDL → DML dependencies and hereby reordering migration files all the time, it's better if we just ensure that all DML pieces of code always runs after all DDL ones.