[heat][qa][requirements] Pinning tempest in stable/xena constraints
Hello,
I have had some local discussions with gmann, but I'd really like to move this discussion forward to fix the broken stable/xena gate in heat so I will start this thread, hoping the thread can provide more context behind my proposal.
Historically stable branches of heat have been frequently affected by any change in requirements of tempest. This is mainly because in our CI we install our own in-tree integration tests[1] into tempest venv where tempest and heat-tempest-plugin are installed. Because in-tree integration tests are tied to that specific stable branch, this has been often causing conflicts in requirements (master constraint vs stable/X constraint).
[1] https://github.com/openstack/heat/tree/master/heat_integrationtests
In the past we changed our test installation[2] to use stable constraint to avoid this conflicts, but this approach does no longer work since stable/xena because
1. stable/xena u-c no longer includes tempest
2. latest tempest CAN'T be installed with stable/xena u-c because current tempest requires fasteners>=0.16.0 which conflicts with 0.14.1 in stable/xena u-c.
[2] https://review.opendev.org/c/openstack/heat/+/803890 https://review.opendev.org/c/openstack/heat/+/848215
I've proposed the change to pin tempest[3] in stable/xena u-c so that people can install tempest with stable/xena u-c. [3] https://review.opendev.org/c/openstack/requirements/+/878228
I understand the reason tempest was removed from u-c was that we should use the latest tempest to test recent stable releases.I agree we can keep tempest excluded for stable/yoga and onwards because tempest is installable with their u-c, but stable/xena u-c is no longer compatible with master. Adding pin to xena u-c does not mainly affect the policy to test stable branches with latest tempest because for that we anyway need to use more recent u-c.
I'm still trying to find out the workaround within heat but IMO adding tempest pin to stable/xena u-c is harmless but beneficial in case anyone is trying to use tempest with stable/xena u-c.
Thank you, Takashi Kajinami
I know, I'm whining a lot about usage of u-c for such projects, but I'm just gonna say that u-c is also might be used for tempest installation itself. So if you're trying to install specific tempest version from the requirements file with providing u-c as constraints while having tempest in u-c - this will break due to pip being unable to resolve that. And installing tempest without constraints also tends to break.
I've used a workaround to filter out u-c to drop tempest from them until xena, so moving this back and force is a bit annoying for the end users.
I know nobody agrees with me here, but I do see u-c as an instruction for end users on how to build their venvs (because these constraints are tested!) to install openstack projects (can build analogy to poetry here) and not CI thing only.
Eventually, we see more troubles with time not in tempest itself, but in tempest plugins, when a new test being added to the plugin, that requires new API but not verifying API microversion or feature availability. These kind of failures we experience quite regularly, couple time during any given cycle, which made us also pin tempest plugin versions in requirements with for every release.
Also I have a feeling that a lot of times we're treating tempest as a CI-only thing, which is also weird and not true for me, since it's valuable tool for operators and being leveraged by rally or refstack to ensure state of production environments.
чт, 30 мар. 2023 г., 04:24 Takashi Kajinami tkajinam@redhat.com:
Hello,
I have had some local discussions with gmann, but I'd really like to move this discussion forward to fix the broken stable/xena gate in heat so I will start this thread, hoping the thread can provide more context behind my proposal.
Historically stable branches of heat have been frequently affected by any change in requirements of tempest. This is mainly because in our CI we install our own in-tree integration tests[1] into tempest venv where tempest and heat-tempest-plugin are installed. Because in-tree integration tests are tied to that specific stable branch, this has been often causing conflicts in requirements (master constraint vs stable/X constraint).
[1] https://github.com/openstack/heat/tree/master/heat_integrationtests
In the past we changed our test installation[2] to use stable constraint to avoid this conflicts, but this approach does no longer work since stable/xena because
stable/xena u-c no longer includes tempest
latest tempest CAN'T be installed with stable/xena u-c because current
tempest requires fasteners>=0.16.0 which conflicts with 0.14.1 in stable/xena u-c.
[2] https://review.opendev.org/c/openstack/heat/+/803890 https://review.opendev.org/c/openstack/heat/+/848215
I've proposed the change to pin tempest[3] in stable/xena u-c so that people can install tempest with stable/xena u-c. [3] https://review.opendev.org/c/openstack/requirements/+/878228
I understand the reason tempest was removed from u-c was that we should use the latest tempest to test recent stable releases.I agree we can keep tempest excluded for stable/yoga and onwards because tempest is installable with their u-c, but stable/xena u-c is no longer compatible with master. Adding pin to xena u-c does not mainly affect the policy to test stable branches with latest tempest because for that we anyway need to use more recent u-c.
I'm still trying to find out the workaround within heat but IMO adding tempest pin to stable/xena u-c is harmless but beneficial in case anyone is trying to use tempest with stable/xena u-c.
Thank you, Takashi Kajinami
On Thu, Mar 30, 2023 at 3:35 PM Dmitriy Rabotyagov noonedeadpunk@gmail.com wrote:
I know, I'm whining a lot about usage of u-c for such projects, but I'm just gonna say that u-c is also might be used for tempest installation itself. So if you're trying to install specific tempest version from the requirements file with providing u-c as constraints while having tempest in u-c - this will break due to pip being unable to resolve that.
To support installing a specific tempest with older stable u-c we probably can try adding upper version instead of requiring a specific version ( like <= 33.0.0 instead of === 33.0.0 ), though I guess this might not be accepted by pip.
And installing tempest without constraints also tends to break.
I didn't really get this point. Do you mind elaborating on this ?
I've used a workaround to filter out u-c to drop tempest from them until xena, so moving this back and force is a bit annoying for the end users.
I know nobody agrees with me here, but I do see u-c as an instruction for end users on how to build their venvs (because these constraints are tested!) to install openstack projects (can build analogy to poetry here) and not CI thing only.
Eventually, we see more troubles with time not in tempest itself, but in tempest plugins, when a new test being added to the plugin, that requires new API but not verifying API microversion or feature availability. These kind of failures we experience quite regularly, couple time during any given cycle, which made us also pin tempest plugin versions in requirements with for every release.
Also I have a feeling that a lot of times we're treating tempest as a CI-only thing, which is also weird and not true for me, since it's valuable tool for operators and being leveraged by rally or refstack to ensure state of production environments.
I tend to agree with these points and these would be the problem caused
mainly by the fact tempest is branchless, IMHO.
чт, 30 мар. 2023 г., 04:24 Takashi Kajinami tkajinam@redhat.com:
Hello,
I have had some local discussions with gmann, but I'd really like to move this discussion forward to fix the broken stable/xena gate in heat so I will start this thread, hoping the thread can provide more context behind my proposal.
Historically stable branches of heat have been frequently affected by any change in requirements of tempest. This is mainly because in our CI we install our own in-tree integration tests[1] into tempest venv where tempest and heat-tempest-plugin are installed. Because in-tree integration tests are tied to that specific stable branch, this has been often causing conflicts in requirements (master constraint vs stable/X constraint).
[1] https://github.com/openstack/heat/tree/master/heat_integrationtests
In the past we changed our test installation[2] to use stable constraint to avoid this conflicts, but this approach does no longer work since stable/xena because
stable/xena u-c no longer includes tempest
latest tempest CAN'T be installed with stable/xena u-c because current
tempest requires fasteners>=0.16.0 which conflicts with 0.14.1 in stable/xena u-c.
[2] https://review.opendev.org/c/openstack/heat/+/803890 https://review.opendev.org/c/openstack/heat/+/848215
I've proposed the change to pin tempest[3] in stable/xena u-c so that people can install tempest with stable/xena u-c. [3] https://review.opendev.org/c/openstack/requirements/+/878228
I understand the reason tempest was removed from u-c was that we should use the latest tempest to test recent stable releases.I agree we can keep tempest excluded for stable/yoga and onwards because tempest is installable with their u-c, but stable/xena u-c is no longer compatible with master. Adding pin to xena u-c does not mainly affect the policy to test stable branches with latest tempest because for that we anyway need to use more recent u-c.
I'm still trying to find out the workaround within heat but IMO adding tempest pin to stable/xena u-c is harmless but beneficial in case anyone is trying to use tempest with stable/xena u-c.
Thank you, Takashi Kajinami
And installing tempest without constraints also tends to break
Basically what I meant is, if user decides not to use u-c for installing tempest due to the conflict, as tempest is part of u-c, then this also tended to fail due to having too fresh libraries, so this older tempest (or even master) is no longer compatible. But yeah, master tempest will be fixed soonish to match these newer dependencies, still you can easily get unlucky. So what I was saying - it's better to use u-c for installing tempest itself.
чт, 30 мар. 2023 г., 08:54 Takashi Kajinami tkajinam@redhat.com:
On Thu, Mar 30, 2023 at 3:35 PM Dmitriy Rabotyagov < noonedeadpunk@gmail.com> wrote:
I know, I'm whining a lot about usage of u-c for such projects, but I'm just gonna say that u-c is also might be used for tempest installation itself. So if you're trying to install specific tempest version from the requirements file with providing u-c as constraints while having tempest in u-c - this will break due to pip being unable to resolve that.
To support installing a specific tempest with older stable u-c we probably can try adding upper version instead of requiring a specific version ( like <= 33.0.0 instead of === 33.0.0 ), though I guess this might not be accepted by pip.
And installing tempest without constraints also tends to break.
I didn't really get this point. Do you mind elaborating on this ?
I've used a workaround to filter out u-c to drop tempest from them until xena, so moving this back and force is a bit annoying for the end users.
I know nobody agrees with me here, but I do see u-c as an instruction for end users on how to build their venvs (because these constraints are tested!) to install openstack projects (can build analogy to poetry here) and not CI thing only.
Eventually, we see more troubles with time not in tempest itself, but in tempest plugins, when a new test being added to the plugin, that requires new API but not verifying API microversion or feature availability. These kind of failures we experience quite regularly, couple time during any given cycle, which made us also pin tempest plugin versions in requirements with for every release.
Also I have a feeling that a lot of times we're treating tempest as a CI-only thing, which is also weird and not true for me, since it's valuable tool for operators and being leveraged by rally or refstack to ensure state of production environments.
I tend to agree with these points and these would be the problem caused
mainly by the fact tempest is branchless, IMHO.
чт, 30 мар. 2023 г., 04:24 Takashi Kajinami tkajinam@redhat.com:
Hello,
I have had some local discussions with gmann, but I'd really like to move this discussion forward to fix the broken stable/xena gate in heat so I will start this thread, hoping the thread can provide more context behind my proposal.
Historically stable branches of heat have been frequently affected by any change in requirements of tempest. This is mainly because in our CI we install our own in-tree integration tests[1] into tempest venv where tempest and heat-tempest-plugin are installed. Because in-tree integration tests are tied to that specific stable branch, this has been often causing conflicts in requirements (master constraint vs stable/X constraint).
[1] https://github.com/openstack/heat/tree/master/heat_integrationtests
In the past we changed our test installation[2] to use stable constraint to avoid this conflicts, but this approach does no longer work since stable/xena because
stable/xena u-c no longer includes tempest
latest tempest CAN'T be installed with stable/xena u-c because
current tempest requires fasteners>=0.16.0 which conflicts with 0.14.1 in stable/xena u-c.
[2] https://review.opendev.org/c/openstack/heat/+/803890 https://review.opendev.org/c/openstack/heat/+/848215
I've proposed the change to pin tempest[3] in stable/xena u-c so that people can install tempest with stable/xena u-c. [3] https://review.opendev.org/c/openstack/requirements/+/878228
I understand the reason tempest was removed from u-c was that we should use the latest tempest to test recent stable releases.I agree we can keep tempest excluded for stable/yoga and onwards because tempest is installable with their u-c, but stable/xena u-c is no longer compatible with master. Adding pin to xena u-c does not mainly affect the policy to test stable branches with latest tempest because for that we anyway need to use more recent u-c.
I'm still trying to find out the workaround within heat but IMO adding tempest pin to stable/xena u-c is harmless but beneficial in case anyone is trying to use tempest with stable/xena u-c.
Thank you, Takashi Kajinami
On 2023-03-30 11:20:43 +0900 (+0900), Takashi Kajinami wrote: [...]
latest tempest CAN'T be installed with stable/xena u-c because current tempest requires fasteners>=0.16.0 which conflicts with 0.14.1 in stable/xena u-c.
[...]
Won't this situation sort itself out in a few weeks when the Tempest master branch officially ceases support for stable/xena?
But more generally, Tempest isn't expected to be coinstallable with stable branches of projects, it's supposed to be installed into an isolated venv or possibly even onto an entirely separate VM. Why not move the problem tests into the heat-tempest-plugin repository instead, since it should be properly coinstallable with Tempest?
---- On Thu, 30 Mar 2023 07:17:39 -0700 Jeremy Stanley wrote ---
On 2023-03-30 11:20:43 +0900 (+0900), Takashi Kajinami wrote: [...]
latest tempest CAN'T be installed with stable/xena u-c because current tempest requires fasteners>=0.16.0 which conflicts with 0.14.1 in stable/xena u-c.
[...]
Won't this situation sort itself out in a few weeks when the Tempest master branch officially ceases support for stable/xena?
But more generally, Tempest isn't expected to be coinstallable with stable branches of projects, it's supposed to be installed into an isolated venv or possibly even onto an entirely separate VM. Why not move the problem tests into the heat-tempest-plugin repository instead, since it should be properly coinstallable with Tempest?
This is not related to stable/xena or heat tests. Grenade job running on immediately supported branch from EM branch where the base is EM branch using old tempest and stable constraints and target use master tempest and constraints. When you run tempest on target, it causes an issue as constraints var are not set properly for the target.
-gmann
-- Jeremy Stanley
On 2023-03-30 19:12:46 -0700 (-0700), Ghanshyam Mann wrote: [...]
This is not related to stable/xena or heat tests. Grenade job running on immediately supported branch from EM branch where the base is EM branch using old tempest and stable constraints and target use master tempest and constraints. When you run tempest on target, it causes an issue as constraints var are not set properly for the target.
We're still running grenade jobs that test upgrades from stable/wallaby to stable/xena? I thought by policy we dropped those when stable/wallaby entered extended maintenance, and that grenade only intended to support upgrading from maintained stable branches.
---- On Fri, 31 Mar 2023 04:25:49 -0700 Jeremy Stanley wrote ---
On 2023-03-30 19:12:46 -0700 (-0700), Ghanshyam Mann wrote: [...]
This is not related to stable/xena or heat tests. Grenade job running on immediately supported branch from EM branch where the base is EM branch using old tempest and stable constraints and target use master tempest and constraints. When you run tempest on target, it causes an issue as constraints var are not set properly for the target.
We're still running grenade jobs that test upgrades from stable/wallaby to stable/xena? I thought by policy we dropped those when stable/wallaby entered extended maintenance, and that grenade only intended to support upgrading from maintained stable branches.
We do not need to run as you mentioned, but we try to keep it running as long as it can pass. This is my last attempt to fix on EM upgrade and in the next failure, I need to stop fixing and better to stop the grenade there.
-gmann
-- Jeremy Stanley
---- On Wed, 29 Mar 2023 19:20:43 -0700 Takashi Kajinami wrote ---
Hello,
I have had some local discussions with gmann, but I'd really like to move this discussion forwardto fix the broken stable/xena gate in heat so I will start this thread, hoping the thread can providemore context behind my proposal. Historically stable branches of heat have been frequently affected by any change in requirementsof tempest. This is mainly because in our CI we install our own in-tree integration tests[1] intotempest venv where tempest and heat-tempest-plugin are installed. Because in-tree integration testsare tied to that specific stable branch, this has been often causing conflicts in requirements(master constraint vs stable/X constraint).
Let me explain the issue here. It is not because of using tempest from upper constraints or branchless things, it is because we are not setting the tempest venv constraints correctly for the target tempest run in the grenade job.
We fixed the tempest venv constraints setting for the tempest test run on the base branch[1] but forgot to do the same for the target branch test run. As we do not have any grenade job except heat which is running tempest on the target branch in the grenade job, we could not face this issue and heat testing unhide it. I then reproduce it on a normal grenade job by running the tempest on target and the same issue[2][3].
The issue is when base and target branches have different Tempest and constraints to use (for example, stable/wallaby uses old tempest and stable/wallaby constraints, but stable/xena use tempest master and master constraints); in such cases, we need to set proper constraints defined in devstack and then run tempest. It will happen in the grenade job running on the immediately supported branch of the latest EM.
I have pushed the grenade fix[4] and testing it by applying the same in heat[5]. If it work then I will push heat change form master itself and backported till stable/xena, so we fix it for all future EM/stable branches.
[1] https://review.opendev.org/q/topic:bug%252F2003993 [2] https://review.opendev.org/c/openstack/grenade/+/878247/1 [3] https://zuul.opendev.org/t/openstack/build/1b503d359717459c9c77010608068e27/... [4] https://review.opendev.org/c/openstack/grenade/+/879113 [5] https://review.opendev.org/c/openstack/heat/+/872055
-gmann
[1]https://github.com/openstack/heat/tree/master/heat_integrationtests In the past we changed our test installation[2] to use stable constraint to avoid this conflicts,but this approach does no longer work since stable/xena because
- stable/xena u-c no longer includes tempest
- latest tempest CAN'T be installed with stable/xena u-c because current tempest requires fasteners>=0.16.0 which conflicts with 0.14.1 in stable/xena u-c.
[2]https://review.opendev.org/c/openstack/heat/+/803890https://review.opendev.o... I've proposed the change to pin tempest[3] in stable/xena u-c so that people can install tempestwith stable/xena u-c. [3] https://review.opendev.org/c/openstack/requirements/+/878228 I understand the reason tempest was removed from u-c was that we should use the latest tempestto test recent stable releases.I agree we can keep tempest excluded for stable/yoga and onwardsbecause tempest is installable with their u-c, but stable/xena u-c is no longer compatible with master.Adding pin to xena u-c does not mainly affect the policy to test stable branches with latest tempestbecause for that we anyway need to use more recent u-c. I'm still trying to find out the workaround within heat but IMO adding tempest pin to stable/xena u-cis harmless but beneficial in case anyone is trying to use tempest with stable/xena u-c.
Thank you, Takashi Kajinami
On Fri, Mar 31, 2023 at 11:26 AM Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Wed, 29 Mar 2023 19:20:43 -0700 Takashi Kajinami wrote ---
Hello,
I have had some local discussions with gmann, but I'd really like to
move this discussion forwardto fix the broken stable/xena gate in heat so I will start this thread, hoping the thread can providemore context behind my proposal.
Historically stable branches of heat have been frequently affected by
any change in requirementsof tempest. This is mainly because in our CI we install our own in-tree integration tests[1] intotempest venv where tempest and heat-tempest-plugin are installed. Because in-tree integration testsare tied to that specific stable branch, this has been often causing conflicts in requirements(master constraint vs stable/X constraint).
Let me explain the issue here. It is not because of using tempest from upper constraints or branchless things, it is because we are not setting the tempest venv constraints correctly for the target tempest run in the grenade job.
We fixed the tempest venv constraints setting for the tempest test run on the base branch[1] but forgot to do the same for the target branch test run. As we do not have any grenade job except heat which is running tempest on the target branch in the grenade job, we could not face this issue and heat testing unhide it. I then reproduce it on a normal grenade job by running the tempest on target and the same issue[2][3].
The issue is when base and target branches have different Tempest and constraints to use (for example, stable/wallaby uses old tempest and stable/wallaby constraints, but stable/xena use tempest master and master constraints); in such cases, we need to set proper constraints defined in devstack and then run tempest. It will happen in the grenade job running on the immediately supported branch of the latest EM.
This is the core problem in heat, which is conflicting what has been done in heat testing. During tests after upgrade we run not only tempest + heat-tempest-plugin tests but also in-tree heat integration tests which test more actual resources. However in-tree integration tests are dependent on a specific stable/requirement. So when we run tests in stable/xena then we need stable/xena constraints installed in venv, which means we need to install tempest which is compatible with stable/xena uc, rather than master tempest. For this sake, I'm asking for adding requirements so that we can install tempest with stable/xena u-c. (Currently we do not explicitly install tempest but it is installed as a dependency of heat-tempest-plugin. I tried to set an explicit tempest version but it has been failing for some reason.)
https://review.opendev.org/c/openstack/heat/+/878610
If running tempest tests after upgrade is not commonly done then we probably can replace tempest by more simple ones as is done for the core services such as keystone, or at least we can get rid of integration tests. Though we still likely face an issue with our normal integration tests which run the same set of tests.
I have pushed the grenade fix[4] and testing it by applying the same in heat[5]. If it work then I will push heat change form master itself and backported till stable/xena, so we fix it for all future EM/stable branches.
[1] https://review.opendev.org/q/topic:bug%252F2003993 [2] https://review.opendev.org/c/openstack/grenade/+/878247/1 [3] https://zuul.opendev.org/t/openstack/build/1b503d359717459c9c77010608068e27/... [4] https://review.opendev.org/c/openstack/grenade/+/879113 [5] https://review.opendev.org/c/openstack/heat/+/872055
-gmann
[1]https://github.com/openstack/heat/tree/master/heat_integrationtests In the past we changed our test installation[2] to use stable
constraint to avoid this conflicts,but this approach does no longer work since stable/xena because
- stable/xena u-c no longer includes tempest
- latest tempest CAN'T be installed with stable/xena u-c because
current tempest requires fasteners>=0.16.0 which conflicts with 0.14.1 in stable/xena u-c.
[2]
https://review.opendev.org/c/openstack/heat/+/803890https://review.opendev.o...
I've proposed the change to pin tempest[3] in stable/xena u-c so that
people can install tempestwith stable/xena u-c.
[3] https://review.opendev.org/c/openstack/requirements/+/878228 I understand the reason tempest was removed from u-c was that we should
use the latest tempestto test recent stable releases.I agree we can keep tempest excluded for stable/yoga and onwardsbecause tempest is installable with their u-c, but stable/xena u-c is no longer compatible with master.Adding pin to xena u-c does not mainly affect the policy to test stable branches with latest tempestbecause for that we anyway need to use more recent u-c.
I'm still trying to find out the workaround within heat but IMO adding
tempest pin to stable/xena u-cis harmless but beneficial in case anyone is trying to use tempest with stable/xena u-c.
Thank you, Takashi Kajinami
On Fri, Mar 31, 2023 at 12:27 PM Takashi Kajinami tkajinam@redhat.com wrote:
On Fri, Mar 31, 2023 at 11:26 AM Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Wed, 29 Mar 2023 19:20:43 -0700 Takashi Kajinami wrote ---
Hello,
I have had some local discussions with gmann, but I'd really like to
move this discussion forwardto fix the broken stable/xena gate in heat so I will start this thread, hoping the thread can providemore context behind my proposal.
Historically stable branches of heat have been frequently affected by
any change in requirementsof tempest. This is mainly because in our CI we install our own in-tree integration tests[1] intotempest venv where tempest and heat-tempest-plugin are installed. Because in-tree integration testsare tied to that specific stable branch, this has been often causing conflicts in requirements(master constraint vs stable/X constraint).
Let me explain the issue here. It is not because of using tempest from upper constraints or branchless things, it is because we are not setting the tempest venv constraints correctly for the target tempest run in the grenade job.
We fixed the tempest venv constraints setting for the tempest test run on the base branch[1] but forgot to do the same for the target branch test run. As we do not have any grenade job except heat which is running tempest on the target branch in the grenade job, we could not face this issue and heat testing unhide it. I then reproduce it on a normal grenade job by running the tempest on target and the same issue[2][3].
The issue is when base and target branches have different Tempest and constraints to use (for example, stable/wallaby uses old tempest and stable/wallaby constraints, but stable/xena use tempest master and master constraints); in such cases, we need to set proper constraints defined in devstack and then run tempest. It will happen in the grenade job running on the immediately supported branch of the latest EM.
This is the core problem in heat, which is conflicting what has been done in heat testing. During tests after upgrade we run not only tempest + heat-tempest-plugin tests but also in-tree heat integration tests which test more actual resources. However in-tree integration tests are dependent on a specific stable/requirement. So when we run tests in stable/xena then we need stable/xena constraints installed in venv, which means we need to install tempest which is compatible with stable/xena uc, rather than master tempest. For this sake, I'm asking for adding requirements so that we can install tempest with stable/xena u-c. (Currently we do not explicitly install tempest but it is installed as a dependency of heat-tempest-plugin. I tried to set an explicit tempest version but it has been failing for some reason.)
https://review.opendev.org/c/openstack/heat/+/878610
If running tempest tests after upgrade is not commonly done then we probably can replace tempest by more simple ones as is done for the core services such as keystone, or at least we can get rid of integration tests. Though we still likely face an issue with our normal integration tests which run the same set of tests.
Hmm. Looking at the result of integration tests in https://review.opendev.org/c/openstack/heat/+/872055 , it seems heat integration tests in stable/xena works with master constraints. So we probably can use master constraints for now but in the future when any backport incompatibility affects integration tests then we have to find out the way to switch to stable constraints at that time.
I have pushed the grenade fix[4] and testing it by applying the same in heat[5]. If it work then I will push heat change form master itself and backported till stable/xena, so we fix it for all future EM/stable branches.
[1] https://review.opendev.org/q/topic:bug%252F2003993 [2] https://review.opendev.org/c/openstack/grenade/+/878247/1 [3] https://zuul.opendev.org/t/openstack/build/1b503d359717459c9c77010608068e27/... [4] https://review.opendev.org/c/openstack/grenade/+/879113 [5] https://review.opendev.org/c/openstack/heat/+/872055
-gmann
[1]https://github.com/openstack/heat/tree/master/heat_integrationtests In the past we changed our test installation[2] to use stable
constraint to avoid this conflicts,but this approach does no longer work since stable/xena because
- stable/xena u-c no longer includes tempest
- latest tempest CAN'T be installed with stable/xena u-c because
current tempest requires fasteners>=0.16.0 which conflicts with 0.14.1 in stable/xena u-c.
[2]
https://review.opendev.org/c/openstack/heat/+/803890https://review.opendev.o...
I've proposed the change to pin tempest[3] in stable/xena u-c so that
people can install tempestwith stable/xena u-c.
[3] https://review.opendev.org/c/openstack/requirements/+/878228 I understand the reason tempest was removed from u-c was that we
should use the latest tempestto test recent stable releases.I agree we can keep tempest excluded for stable/yoga and onwardsbecause tempest is installable with their u-c, but stable/xena u-c is no longer compatible with master.Adding pin to xena u-c does not mainly affect the policy to test stable branches with latest tempestbecause for that we anyway need to use more recent u-c.
I'm still trying to find out the workaround within heat but IMO adding
tempest pin to stable/xena u-cis harmless but beneficial in case anyone is trying to use tempest with stable/xena u-c.
Thank you, Takashi Kajinami
participants (4)
-
Dmitriy Rabotyagov
-
Ghanshyam Mann
-
Jeremy Stanley
-
Takashi Kajinami