As always, thanks a lot for your explanation with the needed references. Now I understand the process. On Thu, Sep 5, 2024 at 9:11 PM Ghanshyam Mann <gmann@ghanshyammann.com> wrote:
Hello all: Because I think I'm having some communication problems about [1], I would like to write it down in a mail. This release patch for 2024.2 is
There are other examples done in previous releases that support what I'm saying:* 2023.2:** https://review.opendev.org/c/openstack/releases/+/896158** https://github.com/openstack/tempest/commit/3926608631111a0ec93b3c44129d0cb2... 2023.1:** https://review.opendev.org/c/openstack/releases/+/877840** https://github.com/openstack/tempest/commit/7c7d0fdd67022ad48ed128c997dfcc3b... BTW, despite not having the stable 2024.2 branch in "requirements", the
---- On Thu, 05 Sep 2024 00:46:13 -0700 Rodolfo Alonso Hernandez wrote --- pointing to [2]. However, the requirements branch used in tempest was tagged as 2024.1. That means the tempest release for 2024.2 will use the requirements from 2024.1. link https://releases.openstack.org/constraints/upper/2024.2 is valid and points to master (once the stable branch is created, that will point to 2024.2).
Regards.
[1] https://review.opendev.org/c/openstack/releases/+/927833[2]https://review.opendev.org/c/openstack/tempest/+/927831 <https://review.opendev.org/c/openstack/releases/+/927833%5B2%5Dhttps://review.opendev.org/c/openstack/tempest/+/927831>
I tried explaining the process in Gerrit, but I can add it here, too. Tempest release and its constraints are one of the complex things we need to take care of considering two factors: 1. Branchless tempest, which is meant to test the supported stable and master with Tempest master 2. Compatible constraints for any Tempest release. It has to be the *latest* stable constraints and not the under-development master constraints
I have explained the branchless Tempest and its compatible constraints problem/solution in the ML thread[1] and also prepared the tempest doc[2]. Please let me know if there are any queries on that, and I will be happy to answer them.
Here is the thing which might have confused you about using stable/2024.1 vs 2024.2 constraints
1. Intermediate release of the cycle: When we do Temepst intermediate release in between cycles, we cannot use the master constraints. Because they are under development and can change after we pin them in the Tempest release. For example: Tempest 'tag-i' is released with the master constraints, which work fine with oslo.policy 4.3.0 (the constraints in master u-c), but later, we bump the solo. policy to 4.4.0 in master constraints which is not compatible with Tempest 'tag-i' then 'tag-i' is broken and cannot be fixed as it has already been released. That is the reason why we cannot use under-development master constraints in any intermediate release.
2. Final Tempest release for the cycle: When we do the Tempest final release for the cycle, the master constraint of that cycle is frozen, and we can use it for the final release. This means Tempest's final release of 2024.2 will use 2024.2 constraints.
The example you mentioned is the final release of Tempest, and that is why you see that cycle constraints are being used for that release.
You can see the below example of intermediate release where you can see the last stable constraints are used and not that cycle master constraints.
Tempest 34.2.0 intermediate release in bobcat (2023.2), constrained used is stable/2023.1: - https://review.opendev.org/q/topic:%22tempest-34-2-0-release%22
Tempest 37.0.0 intermediate release in Caracal (2024.1), constrained used is stable/2023.2: - https://review.opendev.org/c/openstack/releases/+/908346 - https://review.opendev.org/c/openstack/tempest/+/908345
[1] https://lists.openstack.org/pipermail/openstack-discuss/2020-April/014388.ht... [2] https://docs.openstack.org/tempest/latest/requirement_upper_constraint_for_t...
-gmann