Open Stack

> In the meantime however, I do think tripleo-validations needs the
check-requirements job added since it depends on tripleo-common (in g-r)
and tripleo-validations is itself in projects.txt.

Good point. I'm going to submit it today.

On Fri, May 21, 2021 at 3:57 PM James Slagle <james.slagle at gmail.com> wrote:

>
>
> On Wed, May 19, 2021 at 4:07 AM Jiri Podivin <jpodivin at redhat.com> wrote:
>
>>
>> Which brings me to my point. The openstack/requirements does provide one
>> rather essential service for us. In the form of upper-constraints for our
>> pip builds.
>> While we are mostly installing software through rpm, many CI jobs use pip
>> in some fashion. Without upper constraints, pip pulls aggressively the
>> newest version available and compatible with other packages.
>> Which causes several issues, noted by even pip people.
>>
>> There is also a question of security. There is a possibility of a bad
>> actor introducing a package with an extremely high version number.
>> Such a package would get precedence over the legitimate releases. In
>> fact, just this sort of attack was spotted in the wild.[1]
>>
>
> It should be noted however that upper-constraints.txt only applies in CI.
> If you "pip install python-tripleoclient" in a fresh virtualenv, you get
> latest releases, assuming they satisfy other dependencies.
>
>
>> Now, nothing is preventing us from using upper requirements, without
>> being in the openstack/requirements projects.
>> On the other hand, if we remove ourselves from the covenant, nothing is
>> stopping the openstack/requirements people from changing versions of the
>> accepted packages
>> without considering the impact it could have on our projects.
>>
>
> This would mean you could potentially have issues pip installing with the
> rest of OpenStack that have accepted the requirements contract. It goes
> back to my original point that I don't think we care.
>
> Overall, I don't get the sense there is broad agreement about this change,
> and it is not completely understood, myself included here. We should likely
> hold off on making any decisions until time allows for a more thorough deep
> dive into the implications.
>
> In the meantime however, I do think tripleo-validations needs the
> check-requirements job added since it depends on tripleo-common (in g-r)
> and tripleo-validations is itself in projects.txt.
>
> --
> -- James Slagle
> --
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210521/2d136f62/attachment-0001.html>