<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 14, 2021 at 6:41 AM Marios Andreou <<a href="mailto:marios@redhat.com">marios@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, May 13, 2021 at 9:41 PM James Slagle <<a href="mailto:james.slagle@gmail.com" target="_blank">james.slagle@gmail.com</a>> wrote:<br>
><br>
> I'd like to propose that TripleO opt out of dependency management by removing tripleo-common from global-requirements.txt.  I do not feel that the global dependency management brings any advantages or anything needed for TripleO. I can't think of any reason to enforce the ability to be globally pip installable with the rest of OpenStack.<br>
<br>
To add a bit more context as to how this discussion came about, we<br>
tried to remove tripleo-common from global-requirements and the<br>
check-requirements jobs in tripleoclient caused [1] as a result.<br>
<br>
So we need to decide whether to continue to be part of that<br>
requirements contract [2] or if we will do what is proposed here and<br>
remove ourselves altogether.<br>
If we decide _not_ to implement this proposal then we will also have<br>
to add the requirements-check jobs in tripleo-ansible [3] and<br>
tripleo-validations [4] as they are currently missing.<br>
<br>
><br>
> Two of our most critical projects, tripleoclient and tripleo-common do not even put many of their data files in the right place where our code expects them when they are pip installed. So, I feel fairly confident that no one is pip installing TripleO and relying on global requirements enforcement.<br>
<br>
I don't think this is _just_ about pip installs. It is generally about<br>
the contents of each project requirements.txt. As part of the<br>
requirements contract, it means that those repos with which we are<br>
participating (the ones in projects.txt [5]) are protected against<br>
other projects making any breaking changes in _their_<br>
requirements.txt. Don't the contents of requirements.txt also end up<br>
in the .spec file from which we are building rpm e.g. [6] for tht? In<br>
which case if we remove this and just stop catching any breaking<br>
changes in the check/gate check-requirements jobs, I suspect we will<br>
just move the problem to the rpm build and it will fail there.<br></blockquote><div><br></div><div>I don't see that in the spec file. Unless there is some other automation somewhere that regenerates all of the BuildRequires/Requires and modifies them to match requirements.txt/test-requirements.txt?</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
><br>
> One potential advantage of not being in global-requirements.txt is that our unit tests and functional tests could actually test the same code. As things stand today, our unit tests in projects that depend on tripleo-common are pinned to the version in global-requirements.txt, while our functional tests currently run with tripleo-common from master (or included depends-on).<br>
<br>
I don't think one in particular is a very valid point though - as<br>
things currently stand in global-requirements we aren't 'pinning' all<br>
we have there is "tripleo-common!=11.3.0  # Apache-2.0" [7] to avoid<br>
(I assume) some bad release we made.<br></blockquote><div><br></div><div>tripleo-common is pinned to the latest release when it's pip installed in the venv, instead of using latest git (and including depends-on). You're right that it's probably what we want to keep doing, and this is probably not related to opting out of g-r. Especially since we don't want to require latest git of a dependency when running unit tests locally. However it is worth noting that our unit tests (tox) and functional tests (tripleo-ci) use different code for the dependencies. That was not obvious to me and others on the surface. Perhaps we could add additional tox jobs that do require the latest tripleo-common from git to also cover that scenario.</div><div><br></div><div>Here's an example:<br></div><div><a href="https://review.opendev.org/c/openstack/python-tripleoclient/+/787907">https://review.opendev.org/c/openstack/python-tripleoclient/+/787907</a></div><div><a href="https://review.opendev.org/c/openstack/tripleo-common/+/787906">https://review.opendev.org/c/openstack/tripleo-common/+/787906</a></div><div><br></div><div>The tripleo-common patch fails unit tests as expected, the tripleoclient which depends-on the tripleo-common patch passes unit tests, but fails functional. I'd rather see that failure caught by a unit test as well.<br></div><div></div><br clear="all"></div>-- <br><div dir="ltr" class="gmail_signature">-- James Slagle<br>--</div></div>