Open Stack

> 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 at redhat.com>:

>
>
> 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/e9877051/attachment-0001.htm>