[heat][qa][requirements] Pinning tempest in stable/xena constraints

Takashi Kajinami tkajinam at redhat.com
Thu Mar 30 06:54:32 UTC 2023


On Thu, Mar 30, 2023 at 3:35 PM Dmitriy Rabotyagov <noonedeadpunk at 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 at 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
>>
>> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230330/8d8eac2a/attachment.htm>


More information about the openstack-discuss mailing list