[ 英语 | 印度尼西亚语 | 俄语 ]

周期性工作

发布

我们的发布频率在 发布 中讨论。

OSA CLI 工具

OpenStack-Ansible 过去使用一个脚本来更新所有内容，这使得维护变得困难，并且与分支特定性很高。这使得用户难以使用上游 SHA 的更新，或者以自己的节奏更新角色。

此后，OpenStack-Ansible 同意提供发布到 openstack-ansible 代码树所需的更多元数据。这使得发布工具更加灵活和轻量化。

所有函数都已分离，并包含在一个额外的控制台脚本 openstack-ansible-releases 中。

默认情况下，脚本的依赖项未安装，以最大程度地减少普通用户的依赖项数量。为了确保脚本安装了所有必需的依赖项，您可以运行

pip3 install -e git+https://opendev.org/openstack/openstack-ansible#egg=openstack-ansible[releases]

每个子命令默认包含帮助信息。

更新上游 SHA

通过使用 openstack-ansible-releases bump_upstream_shas 更新 OpenStack-Ansible 的依赖项。此脚本根据其 _git_track_branch 值更新项目引用的 SHA，这些 SHA 位于 inventory/group_vars/<service_group>/source_git.yml 文件中。

更新 OpenStack-Ansible 角色

通过 openstack-ansible-releases bump_roles 更新角色到其每个分支的最新版本。

这可以执行多项操作

  • 将 ansible-role-requirements 冻结到它们跟踪的分支的最新 SHA。

  • 复制与冻结相关的发行说明。

  • 解冻 master 分支。

除非明确要求用于发布里程碑，否则 master 分支不会被冻结，使用命令 openstack-ansible-releases freeze_roles_for_milestone

更新所需的集合

通过 openstack-ansible-releases bump_collections 更新集合到其最新版本。

请注意，仅支持类型为 git 的集合。应手动更新从 Ansible Galaxy 安装的集合。

检查当前引脚状态

您可以通过运行 openstack-ansible-releases check_pins 来检查 openstack-ansible 仓库中使用的当前 PyPI 引脚。这将显示一个表格，显示 OSA 中的当前引脚以及 PyPI 上可用的引脚。

这不会修补 global-requirements-pins，因为这应该是一个手动操作。请参阅 开发周期检查表，以了解何时更新 global-requirements-pins。

在发布仓库中添加补丁

当更新 SHA 和角色的补丁已着陆后，您可以将父 SHA 建议为发布仓库中的发布。

可以使用 new-release 命令来完成，然后编辑用于 openstack-ansible 的 SHA。有关此命令的说明，请参阅 new_releases 页面。

请注意，Stein 之前的分支需要清理由 new_releases 生成的 YAML 文件，因为它将包含所有角色和 openstack-ansible 仓库 SHA。我们决定不再标记角色，因此您需要删除所有与 openstack-ansible 仓库无关的行。

将发布过渡到扩展维护

将发布迁移到 扩展维护 (EM) 状态后，该发布将不再可能进行未来发布。因此，会创建一个新的标签 -em，并且必须基于最新的数字发布。

要将发布过渡到扩展维护，我们需要

  • 等待所有上游仓库过渡到 EM

  • 正常更新 OpenStack-Ansible 角色

  • 更新 <service>_git_install_branch 为 <release>-em，而不是 SHA。

  • 向 openstack/releases 仓库建议一个新的数字发布

  • 建议使用与上一个数字发布相同的 SHA 创建一个 <release>-em 标签。

  • 创建 EM 标签后，将 ansible-role-requirements.yml 中的 version 字段切换到跟踪 stable/<release>。

  • 更新 master 分支中的 index.rst 以反映发布的支持状态

将发布过渡到生命周期结束

当发布达到 生命周期结束 (EOL) 时，会创建一个新的标签 <release>-eol，之后该分支将被删除。项目可以在与 EM 协调迁移完成后随时将分支 EOL。因此，我们不跟踪 EM 的上游服务的 stable/<release> 分支，而仅跟踪我们的角色。同时，有一个协调的截止日期，所有项目都必须 EOL 它们的旧分支。

要将发布过渡到生命周期结束，我们需要

  • 为 OpenStack-Ansible 角色创建一个 -eol 标签

  • 将 ansible-role-requirements.yml 中的 version 字段从 stable/ 分支切换到 -eol 标签。

  • 等待所有项目 EOL

  • 更新 <service>_git_install_branch 变量以使用 -eol 标签而不是 SHA。

  • 为 OpenStack-Ansible 仓库创建一个 -eol 标签

  • 更新 master 分支上的 release 支持状态 index.rst。

开发周期检查表

除了正常的周期目标之外，贡献者可以通过执行以下循环任务来帮助 OpenStack-Ansible 开发团队

  • 到里程碑 1

    • 社区目标确认。

    • 定义受支持的平台发布将运行在其上。删除已弃用平台的测试和支持。

    • 更新 global-requirements-pins、上游 SHA 和所需的集合

  • 到里程碑 2

    • 处理来自上游项目上一个周期的弃用。

    • 处理来自上一个周期的 OpenStack-Ansible 角色的弃用。

    • 刷新角色的静态元素。例如，更新软件版本的特定版本。

    • 更新发布版本组件，例如 Octavia 测试 ampohora 镜像和 Ironic IPA 镜像/内核。

    • 将 ceph_stable_release 提升到集成 OpenStack-Ansible 仓库中的最新 Ceph LTS 发布，以及 ceph_client 角色默认值中。

    • 检查并提升 galera 版本（如果需要）。

    • 检查并提升 rabbitmq 版本（如果需要）。

    • 检查未决的审查并将其移动到合并或放弃，如果不再有效。

    • 更新 global-requirements-pins、上游 SHA 和所需的集合

  • 到里程碑 3

    • 实现功能

    • 更新 global-requirements-pins、上游 SHA 和所需的集合

  • 里程碑 3 之后

    • 功能冻结、错误修复和测试改进。

    • Ansible 版本和集合冻结

  • 在为服务创建新的稳定分支后

    • 更新 <service>_git_track_branch 变量以匹配新的分支名称。

    • 将所有 tempest_plugin_<service>_git_track_branch 设置为 None，以防止对其进行 SHA 更新。

    • 更新上游 SHA

  • 在协调的 OpenStack 发布之前，在 OpenStack-Ansible 发布之前

    • 更新 openstack_hosts 仓库中的发布名称。这将同时提升 RDO 和 Ubuntu Cloud Archive 仓库。

    • 分支所有不属于发布的部分的独立仓库到 gerrit。请参阅治理仓库中的 projects.yaml。手动分支的仓库需要额外的版本，例如更新 .gitreview 或 reno 索引。请参考先前的分支创建，使用 gerrit 中的适当主题（例如：create-stein）。以前的新分支创建可能不同，因为工具/流程可能已经发展，因此请注意需要进行调整的更改。

    • 将 ansible-role-requirements.yml 中的 trackbranch 切换到新分支，并在之后更新 OpenStack-Ansible 角色。

    • 将发布支持的平台添加到 os-compatibility-matrix.html

  • 在官方 OpenStack-Ansible 发布后立即

    • 通过邮件列表向所有贡献者发送感谢信。他们值得。

    • 恢复对 ansible-role-requirements.yml 和 *_git_track_branch 变量所做的更改，以跟踪稳定分支而不是 master。更新上游 SHA。

    • 反映文档中的更改

      • 创建一个补丁到 openstack-manuals 并取消注释 OpenStack-Ansible 在 www/project-data/.yaml 中。

      • 更新 master 分支上的索引页面，以提及最近发布的版本的发布日期，并将其状态设置为维护中。同时，添加一个我们即将开始工作的新的发布。

      • 更新稳定分支上的索引页面，仅提及主题中的发布，而不是所有历史发布。历史数据应仅存在于 master 分支上。

      • 更新升级脚本和文档以跟踪受支持的升级路径

        • 对于 SLURP 发布，在 doc/source/conf.py 中定义 previous_slurp_name。对于非 SLURP - 设置为 False。

        • 更新 doc/source/conf.py 和 deploy-guide/source/conf.py 中的 previous_series_name 和 current_series_name

        • 更新 scripts/gate-check-commit.sh 中的 UPGRADE_SOURCE_RELEASE

        • 更新 scripts/run-upgrade.sh 中的 SUPPORTED_SOURCE_SERIES 和 TARGET_SERIES。 别忘了清理不相关的升级脚本。

        • 添加/删除 SLURP 升级作业所需的作业。此类作业的 ACTION 应定义为 upgrade_。