[All][Neutron] Migrate old DB migration versions to init ops
Hello all: 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. Although this is not a problem per se, there are some inconvenients: - 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. - Some FT tests are still checking the sanity of some migrations [1] implemented a few releases ago. - We are still testing the contract DB migrations. Of course, this is something supported before and we still need to apply those revisions. - "TestWalkMigrationsMysql" and "TestModelsMigrationsMysql", both using MySQL backend, are still affected by LP#1687027. 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. 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: - 1b4c6e320f79_address_scope_support_in_subnetpool: added "address_scope_id" field - 13cfb89f881a_add_is_default_to_subnetpool: added "is_default" field 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. 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. Do you see any inconvenience on this proposal? Am I missing something that I didn't consider? Thank you and regards. [1] https://github.com/openstack/neutron/blob/9fd60ffaac6b178de62dab169c826d52f7...
Hi, Simplification sounds good (I do not take into considerations like "no code fanatic movements" or similar). How this could affect upgrade, I am sure there are deployments older than pike, and those at a point will got for some newer version (I hope we can give them good answers for their problems as Openstack) What do you think about stadium projects? As those have much less activity (as mostly solve one rather specific problem), and much less migration scripts shall we just "merge" those to init ops? I checked quickly a few stadium project and only bgpvpn has newer migration scripts than pike. Regards Lajos Rodolfo Alonso Hernandez <ralonsoh@redhat.com> ezt írta (időpont: 2020. jún. 24., Sze, 15:25):
Hello all:
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.
Although this is not a problem per se, there are some inconvenients: - 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. - Some FT tests are still checking the sanity of some migrations [1] implemented a few releases ago. - We are still testing the contract DB migrations. Of course, this is something supported before and we still need to apply those revisions. - "TestWalkMigrationsMysql" and "TestModelsMigrationsMysql", both using MySQL backend, are still affected by LP#1687027.
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.
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: - 1b4c6e320f79_address_scope_support_in_subnetpool: added "address_scope_id" field - 13cfb89f881a_add_is_default_to_subnetpool: added "is_default" field
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.
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.
Do you see any inconvenience on this proposal? Am I missing something that I didn't consider?
Thank you and regards.
[1] https://github.com/openstack/neutron/blob/9fd60ffaac6b178de62dab169c826d52f7...
On Tue, Jun 30, 2020 at 9:01 PM Lajos Katona <katonalala@gmail.com> wrote:
Hi, Simplification sounds good (I do not take into considerations like "no code fanatic movements" or similar). How this could affect upgrade, I am sure there are deployments older than pike, and those at a point will got for some newer version (I hope we can give them good answers for their problems as Openstack)
What do you think about stadium projects? As those have much less activity (as mostly solve one rather specific problem), and much less migration scripts shall we just "merge" those to init ops? I checked quickly a few stadium project and only bgpvpn has newer migration scripts than pike.
In my understanding, squashing migrations can be done repository by repository. A revision hash of each migration is not changed and head revisions are stored in the database per repository, so it should work. For initial deployments, neutron-db-manage runs all db migrations from the initial revision to a specified revision (release), so it has no problem. For upgrade scenarios, this change just means that we just dropped support upgrade from releases included in squashed migrations. For example, if we squash migrations up to rocky (and create rocky_initial migration) in the neutron repo, we no longer support db migration from releases before rocky. This would be the only difference I see. Thanks, Akihiro
Regards Lajos
Rodolfo Alonso Hernandez <ralonsoh@redhat.com> ezt írta (időpont: 2020. jún. 24., Sze, 15:25):
Hello all:
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.
Although this is not a problem per se, there are some inconvenients: - 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. - Some FT tests are still checking the sanity of some migrations [1] implemented a few releases ago. - We are still testing the contract DB migrations. Of course, this is something supported before and we still need to apply those revisions. - "TestWalkMigrationsMysql" and "TestModelsMigrationsMysql", both using MySQL backend, are still affected by LP#1687027.
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.
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: - 1b4c6e320f79_address_scope_support_in_subnetpool: added "address_scope_id" field - 13cfb89f881a_add_is_default_to_subnetpool: added "is_default" field
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.
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.
Do you see any inconvenience on this proposal? Am I missing something that I didn't consider?
Thank you and regards.
[1]https://github.com/openstack/neutron/blob/9fd60ffaac6b178de62dab169c826d52f7...
Hi, On Tue, Jun 30, 2020 at 10:53 PM Akihiro Motoki <amotoki@gmail.com> wrote:
On Tue, Jun 30, 2020 at 9:01 PM Lajos Katona <katonalala@gmail.com> wrote:
Hi, Simplification sounds good (I do not take into considerations like "no
How this could affect upgrade, I am sure there are deployments older
got for some newer version (I hope we can give them good answers for
code fanatic movements" or similar). than pike, and those at a point will their problems as Openstack)
What do you think about stadium projects? As those have much less
activity (as mostly solve one rather specific problem),
and much less migration scripts shall we just "merge" those to init ops? I checked quickly a few stadium project and only bgpvpn has newer migration scripts than pike.
In my understanding, squashing migrations can be done repository by repository. A revision hash of each migration is not changed and head revisions are stored in the database per repository, so it should work. For initial deployments, neutron-db-manage runs all db migrations from the initial revision to a specified revision (release), so it has no problem. For upgrade scenarios, this change just means that we just dropped support upgrade from releases included in squashed migrations. For example, if we squash migrations up to rocky (and create rocky_initial migration) in the neutron repo, we no longer support db migration from releases before rocky. This would be the only difference I see.
<snip> I wonder if this is acceptable (that an OpenStack service will not support db migrations prior to rocky). What is (or is there?) OpenStack's stance wrt support for upgrades? We are using ocata and plan on upgrading but we don't know when that might happen :-( --ruby
On Thu, Jul 2, 2020 at 10:37 PM Ruby Loo <opensrloo@gmail.com> wrote:
Hi,
On Tue, Jun 30, 2020 at 10:53 PM Akihiro Motoki <amotoki@gmail.com> wrote:
On Tue, Jun 30, 2020 at 9:01 PM Lajos Katona <katonalala@gmail.com> wrote:
Hi, Simplification sounds good (I do not take into considerations like "no code fanatic movements" or similar). How this could affect upgrade, I am sure there are deployments older than pike, and those at a point will got for some newer version (I hope we can give them good answers for their problems as Openstack)
What do you think about stadium projects? As those have much less activity (as mostly solve one rather specific problem), and much less migration scripts shall we just "merge" those to init ops? I checked quickly a few stadium project and only bgpvpn has newer migration scripts than pike.
In my understanding, squashing migrations can be done repository by repository. A revision hash of each migration is not changed and head revisions are stored in the database per repository, so it should work. For initial deployments, neutron-db-manage runs all db migrations from the initial revision to a specified revision (release), so it has no problem. For upgrade scenarios, this change just means that we just dropped support upgrade from releases included in squashed migrations. For example, if we squash migrations up to rocky (and create rocky_initial migration) in the neutron repo, we no longer support db migration from releases before rocky. This would be the only difference I see.
<snip>
I wonder if this is acceptable (that an OpenStack service will not support db migrations prior to rocky). What is (or is there?) OpenStack's stance wrt support for upgrades? We are using ocata and plan on upgrading but we don't know when that might happen :-(
--ruby
It is not true. What we the upstream community recommend is to upgrade the controller node and databases in the fast-foward upgrade manner. Even if the upstream repository just provides database migration from for example Rocky, you can upgrade from a release older than rocky, by upgrading one release by one. In addition, by keeping a specific number of releases in db migrations, operators can still upgrade from more than one old release (if they want). --amotoki
Hi, Exactly, it is not allowed to backport such a change to rocky for example, so on older branches the migration scripts will be there as I see, and you can upgrade to a release which support migration to Victoria for example. Regards lajoskatona Akihiro Motoki <amotoki@gmail.com> ezt írta (időpont: 2020. júl. 3., P, 15:39):
On Thu, Jul 2, 2020 at 10:37 PM Ruby Loo <opensrloo@gmail.com> wrote:
Hi,
On Tue, Jun 30, 2020 at 10:53 PM Akihiro Motoki <amotoki@gmail.com>
On Tue, Jun 30, 2020 at 9:01 PM Lajos Katona <katonalala@gmail.com>
wrote:
Hi, Simplification sounds good (I do not take into considerations like
"no code fanatic movements" or similar).
How this could affect upgrade, I am sure there are deployments older
got for some newer version (I hope we can give them good answers for
wrote: than pike, and those at a point will their problems as Openstack)
What do you think about stadium projects? As those have much less
activity (as mostly solve one rather specific problem),
and much less migration scripts shall we just "merge" those to init ops? I checked quickly a few stadium project and only bgpvpn has newer migration scripts than pike.
In my understanding, squashing migrations can be done repository by repository. A revision hash of each migration is not changed and head revisions are stored in the database per repository, so it should work. For initial deployments, neutron-db-manage runs all db migrations from the initial revision to a specified revision (release), so it has no problem. For upgrade scenarios, this change just means that we just dropped support upgrade from releases included in squashed migrations. For example, if we squash migrations up to rocky (and create rocky_initial migration) in the neutron repo, we no longer support db migration from releases before rocky. This would be the only difference I see.
<snip>
I wonder if this is acceptable (that an OpenStack service will not support db migrations prior to rocky). What is (or is there?) OpenStack's stance wrt support for upgrades? We are using ocata and plan on upgrading but we don't know when that might happen :-(
--ruby
It is not true. What we the upstream community recommend is to upgrade the controller node and databases in the fast-foward upgrade manner. Even if the upstream repository just provides database migration from for example Rocky, you can upgrade from a release older than rocky, by upgrading one release by one. In addition, by keeping a specific number of releases in db migrations, operators can still upgrade from more than one old release (if they want).
--amotoki
On Wed, Jun 24, 2020 at 10:22 PM Rodolfo Alonso Hernandez <ralonsoh@redhat.com> wrote:
Hello all:
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.
Although this is not a problem per se, there are some inconvenients: - 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. - Some FT tests are still checking the sanity of some migrations [1] implemented a few releases ago. - We are still testing the contract DB migrations. Of course, this is something supported before and we still need to apply those revisions. - "TestWalkMigrationsMysql" and "TestModelsMigrationsMysql", both using MySQL backend, are still affected by LP#1687027.
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.
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: - 1b4c6e320f79_address_scope_support_in_subnetpool: added "address_scope_id" field - 13cfb89f881a_add_is_default_to_subnetpool: added "is_default" field
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.
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.
Do you see any inconvenience on this proposal? Am I missing something that I didn't consider?
Thank you and regards.
[1]https://github.com/openstack/neutron/blob/9fd60ffaac6b178de62dab169c826d52f7...
Hi, Simplification sounds good in general. Previously (up to Liberty release or some), we squashed all migrationed up to a specific past release. If you look at the git log of neutron/db/migration/alembic_migrations/versions/kilo_initial.py, you can see an example. However, it was stopped as squashing migrations needs to be done very carefully and even if we don't squash migrations the overhead of alembic migrations is not so high. You now raise this again, so it might be time to revisit it, so I am not against your proposal in general. I am not sure what you mean by "remove some DB migrations". Squashing migrations only related to some tables potentially introduces some confusion. A simpler approach looks like to merge all migrations up to a specific release (queens or rocky?). I think this approach addresses the problems you mentioned above. Thought? Akihiro
participants (4)
-
Akihiro Motoki
-
Lajos Katona
-
Rodolfo Alonso Hernandez
-
Ruby Loo