Uploaded image for project: 'Red Hat 3scale API Management'
  1. Red Hat 3scale API Management
  2. THREESCALE-3630

Automated procedure to hook requirement data migrations on system upgrade

    XMLWordPrintable

Details

    • Task
    • Resolution: Won't Do
    • Critical
    • None
    • None
    • System
    • None
    • 13
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Engineering
    • 3scale 2019-12-23, 3scale 2020-01-13, 3scale 2020-03-09, 3scale 2020-03-23, Invalid Sprint

    Description

      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.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              mcassola Guilherme Cassolato
              Hery Ramihajamalala (Inactive), Miguel Soriano
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: