<div dir="ltr">Hi,<div>Simplification sounds good (I do not take into considerations like "no code fanatic movements" or similar).</div><div>How this could affect upgrade, I am sure there are deployments older than pike, and those at a point will</div><div>got for some newer version (I hope we can give them good answers for their problems as Openstack)</div><div><br></div><div>What do you think about stadium projects? As those have much less activity (as mostly solve one rather specific problem),</div><div>and much less migration scripts shall we just "merge" those to init ops?</div><div>I checked quickly a few stadium project and only bgpvpn has newer migration scripts than pike.</div><div><br></div><div>Regards</div><div>Lajos</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Rodolfo Alonso Hernandez <<a href="mailto:ralonsoh@redhat.com">ralonsoh@redhat.com</a>> ezt írta (időpont: 2020. jún. 24., Sze, 15:25):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello all:<div><br></div><div>Along this years we have increased the number of DB migrations each time we needed a new DB schema. This is good because that means the project is evolving and adding new features.</div><div><br></div><div>Although this is not a problem per se, there are some inconvenients:</div><div>- Every time a system is deployed (for example in the CI using devstack), the initial DB schema is created. Then, each migration is applied sequentially.</div><div>- Some FT tests are still checking the sanity of some migrations [1] implemented a few releases ago.<br></div><div>- We are still testing the contract DB migrations. Of course, this is something supported before and we still need to apply those revisions.</div><div>- "TestWalkMigrationsMysql" and "TestModelsMigrationsMysql", both using MySQL backend, are still affected by LP#1687027.</div><div><br></div><div>The proposal is to remove some DB migrations, starting from Liberty; of course, because all migrations must be applied in a specific order, we should begin from the initial revision, "kilo". The latest migration to be removed should be decided depending on the stable releases support.</div><div><br></div><div>Apart from mitigating or solving some of the commented problems, we can "group" the DB model definition in one place. E.g.: "subnetpools" table is created in "other_extensions_init_ops". This file contains the first table. However is modified in at least two migrations:</div><div>- 1b4c6e320f79_address_scope_support_in_subnetpool: added "address_scope_id" field</div><div>- 13cfb89f881a_add_is_default_to_subnetpool: added "is_default" field</div><div><br></div><div>Instead of having (at least) three places where the "subnetpools" DB schema is defined, we can remove the Mitaka migration and group this definition in just one place.</div><div><br></div><div>One possible issue: some migrations add dependencies on other tables. That means the table the dependency is referring should be created in advance. That implies that, in some cases, the table creation order should be modified. That should never affect subsequent created tables or migrations.</div><div><br></div><div>Do you see any inconvenience on this proposal? Am I missing something that I didn't consider?</div><div><br></div><div>Thank you and regards.</div><div><br></div><div>[1]<a href="https://github.com/openstack/neutron/blob/9fd60ffaac6b178de62dab169c826d52f7bfbb2d/neutron/tests/functional/db/test_migrations.py" target="_blank">https://github.com/openstack/neutron/blob/9fd60ffaac6b178de62dab169c826d52f7bfbb2d/neutron/tests/functional/db/test_migrations.py</a></div><div><br></div></div>
</blockquote></div>