yahoo-eng-team team mailing list archive

[OpenStack Infra <2100770@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/c/openstack/neutron/+/950139
Committed: https://opendev.org/openstack/neutron/commit/6af3801ac822d7825ddfbc62a5c1893605999b3e
Submitter: "Zuul (22348)"
Branch:    master

commit 6af3801ac822d7825ddfbc62a5c1893605999b3e
Author: Slawek Kaplonski <skaplons@xxxxxxxxxx>
Date:   Fri May 16 12:13:14 2025 +0200

    Require alembic db migration scripts to be idempotent
    
    With this patch alembic migration script should always be idempotent.
    This is forced by new functional test which makes sure that migrations
    starting from first alembic migration script from the stable/2024.1
    release is idempotent.
    
    Closes-bug: #2100770
    Change-Id: Ia14f3748245b59850bc21cbc87e04ffbdbb5850f


** Changed in: neutron
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2100770

Title:
  [RFE] Make alembic_migration scripts in neutron idempotent

Status in neutron:
  Fix Released

Bug description:
  There are some (corner) cases, like e.g. we have seen recently while
  doing the RHOSP 17.1 to the RHOSO 18 adoption, then revert and then
  adoption again where something fishy happened with the db migration
  and when it was run second time, it failed due to the fact that table
  it tried to create was already created.

  I know that the issue wasn't really in Neutron in this case but it
  could be somehow "workarounded" in Neutron by making our alembic
  migration scripts to be idempotent.

  We do something like that in some of them already, like e.g.
  https://github.com/openstack/neutron/blob/1ddcb3e8901b87b914ef6c2819b1674190f067d7/neutron/db/migration/alembic_migrations/versions/2023.2/expand/c33da356b165_security_group_default_rules.py#L90
  and it usually was done like that for the patches that we knew we will
  be backporting downstream to some stable version. Making all the
  alembic migration scripts to be idempotent should have few benefits:

  - make the whole db upgrade process a bit more robust in some corner cases,
  - make it easier for the people who are maintaing their own version downstream to backport some specific features to their version if that's needed by them.

  This RFE proposes to do couple of things:
  1. Update existing alembic migration scripts to be idempotent,
  2. Propose functional test which would make sure that every existing and every new alembic migration script is idempotent,
  3. Update alembic migration documentation in Neutron: https://docs.openstack.org/neutron/latest/contributor/alembic_migrations.html so that it will mention that scripts should be idempotent always.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2100770/+subscriptions