重组中子迁移（在“修复”之后）

https://blueprints.launchpad.net/neutron/+spec/reorganize-migrations

当前许多迁移仅适用于某些插件，使其依赖于配置。依赖于配置的迁移路径会带来严重的升级问题。Neutron 数据库正在被重构，无论 Neutron 的配置如何，数据库模式始终保持一致。因此，处理依赖于配置的迁移的逻辑应该被移除；同样，依赖于配置的迁移应该被使其“独立”。 也许它们也应该被合并，以便通过减少迁移的总数，我们或许能够加快数据库升级过程。

此蓝图中的工作依赖于 Neutron 数据库修复蓝图，其规范可以在这里找到：https://review.openstack.org/95738/

问题描述

目前 Neutron 的数据库升级路径中包含超过 100 个迁移。一个迁移通常仅适用于某些插件，如果当前 neutron 配置了不同的插件，则会被跳过。这会造成一个严重的升级问题。

例如，用于测试从 havana 升级到 icehouse 的 devstack 作业失败，因为“metering”服务插件仅在 icehouse 配置中指定；然而，由于它是在 havana 中引入的，一些使其正常工作的基本迁移被跳过了。因此，一旦遇到第一个涉及 metering 数据库模型的迁移，升级就会失败。

这个问题已经通过以一种无论配置值如何，其最终状态都保持一致的方式“修复”neutron 数据库模式来解决。

尽管如此，还有一些事情需要处理

  • 现有的适用于特定插件的数据库迁移必须变得与插件无关

  • 应该移除处理特定插件迁移的逻辑，以防止将来添加特定插件的迁移。

提议的变更

拟议的更改非常简单：移除根据当前配置跳过迁移的逻辑，并使所有迁移“全局”。

由于此蓝图回顾了整个迁移历史，其历史可以追溯到 folsom，这也是一个很好的机会，通过将发布内的迁移合并在一起，并从路径中移除不再受支持的版本，来简化这条相当长的路径。

例如，修订后的路径可以：1) 从 Havana Release 开始

  1. 有一个独立的、与配置无关的迁移到 Icehouse

3) 从 Icehoue 到 trunk 恢复“传统”路径，确保此路径中的所有迁移都与配置无关

这个新的迁移路径必须确保从 Havana 到 Icehouse 的升级/降级的正确操作。为此，此更改将引入

  • 一个新的“Havana”初始状态。这将与配置无关

  • 一个从 Havana 到 Icehouse 及其反向的迁移。此迁移能够将 Havana 数据库升级到 Icehouse 及其反向。此迁移的降级部分假定 Icehouse 模式已经处于“修复”状态。因此，下一步。

  • 在 Icehouse 之前立即执行一个修复步骤。此迁移只有降级部分。这是为了确保数据库处于修复状态，因为新的降级迁移到 Havana 做出此假设。由于修复迁移是幂等的，这不应该成为问题。

注意：如果达成共识，允许运行不受支持版本的用户直接升级到 Icehouse，则可以保留 Folsom 和 Grizzly 的初始状态。

备选方案

另一种选择是保持当前的所有内容不变，并添加一个测试（与 flake8 集成），以防止将新的依赖于插件的迁移添加到路径中； 此外，用于评估是否应执行或跳过迁移的检查将被绕过。

这应该可以工作，但它仍然会给我们留下许多特定于插件的迁移，这可能会让用户感到困惑。此外，源代码树中将留下未使用的代码，最终会变得腐烂。

数据模型影响

将删除 Havana 之前的迁移路径。如果同意为运行现在不受支持的 Grizzly 的用户提供升级到更新版本，则可以用 Grizzly 代替。

Havana 和 Icehouse 之间的发布内迁移（以及可能在 Grizzly 和 Havana 之间）将被合并到一个迁移中。

REST API 影响

无

安全影响

无

通知影响

无

其他最终用户影响

无

性能影响

如果迁移被合并，升级显然会更快。对运行时性能没有影响。

其他部署者影响

已经运行 havana 的操作员应该能够毫无问题地升级到 icehouse。

对于正在运行 Icehouse 的操作员，Havana 降级应该顺利，无论他们是否已经执行了“修复”迁移。

运行 Havana 之前版本的操作员仍然可能受到支持，如果将 Havana 之前的版本保留在迁移路径中。

开发人员影响

将不再能够创建特定于插件的迁移。

实现

总的来说，我们可以预期第一步是移除迁移逻辑，并使所有迁移与配置无关。在第二步中，将定义一个新的初始状态，并将 Icehouse 之前的发布内迁移合并。

负责人

salvatore-orlando akamyshnikova

工作项

即使这些工作项不是正交的，它们之间的依赖关系不一定由本文档中出现的顺序表示。

  • 移除所有 folsom 和 grizzly 迁移。创建一个新的“Havana”初始迁移 - 处于“修复”状态。

  • 使条件迁移无条件

  • 确保在降级方向上也执行修复步骤。这是为了确保无条件降级不会因为数据库未处于“修复”状态而失败。

  • 移除管理条件迁移的逻辑

  • 将 Havana 和 Icehouse 之间的迁移合并到一个迁移中

  • 处理“icehouse”和修复步骤之间的条件迁移

依赖项

数据库迁移重构是此蓝图的前提。 https://review.openstack.org/#/c/95738/

测试

不应添加额外的测试。相反，可能会移除一些关于特定于插件的迁移的单元测试。

现有的 grenade 测试应该足以验证新的升级路径。

文档影响

无

参考资料

无