Open Stack

On Fri, May 21, 2021 at 6:04 PM Jiri Podivin <jpodivin at redhat.com> wrote:
>
>
> > 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

yeah I brought this up in my earlier reply

if we're not removing (and seems like we aren't for now) then we need
to add coverage in tripleo-validations and tripleo-ansible which is
posted there https://review.opendev.org/c/openstack/tripleo-ansible/+/792830

regards, marios


>>
>> --
>> -- James Slagle
>> --