<div dir="ltr">As far as I remember that was added there as a requirement because python-mistralclient was there also and that was broken CI ages ago. Now that we don't require more mistal removing it is likely a good idea. +1 </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 14 May 2021 at 12:42, 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>
<br>
><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>
<br>
One main advantage that isn't mentioned here is that by removing<br>
ourselves from the requirements contract then we are no longer bound<br>
to release tripleo-common first when making a new stable/branch. This<br>
should make it easier to keep gates green on new releases.<br>
<br>
><br>
> The changes needed would be (aiui):<br>
> - Remove tripleo repos from projects.txt<br>
> - Remove check-requirements jobs from those same repos<br>
> - Remove tripleo-common from global-requirements.txt<br>
<br>
yes that list looks right if we decide to go ahead with that. As noted<br>
above my main reservation is that we may end up seeing more<br>
incompatibilities in requirements (and later during package building,<br>
instead of earlier during the check/gate check-requirements jobs).<br>
<br>
regards, marios<br>
<br>
[1] <a href="https://bugs.launchpad.net/tripleo/+bug/1928190" rel="noreferrer" target="_blank">https://bugs.launchpad.net/tripleo/+bug/1928190</a><br>
[2] <a href="https://docs.openstack.org/project-team-guide/dependency-management.html#enforcement-in-projects" rel="noreferrer" target="_blank">https://docs.openstack.org/project-team-guide/dependency-management.html#enforcement-in-projects</a><br>
[3] <a href="https://opendev.org/openstack/tripleo-ansible/src/commit/5b160e8d02acbaaec67df66a5a204e0c0d08366b/zuul.d/layout.yaml#L3" rel="noreferrer" target="_blank">https://opendev.org/openstack/tripleo-ansible/src/commit/5b160e8d02acbaaec67df66a5a204e0c0d08366b/zuul.d/layout.yaml#L3</a><br>
[4] <a href="https://opendev.org/openstack/tripleo-validations/src/commit/edf9ee1f34c92e3b8c70bf3d81c72de5ddc7cba0/zuul.d/layout.yaml#L3" rel="noreferrer" target="_blank">https://opendev.org/openstack/tripleo-validations/src/commit/edf9ee1f34c92e3b8c70bf3d81c72de5ddc7cba0/zuul.d/layout.yaml#L3</a><br>
[5] <a href="https://github.com/openstack/requirements/blob/ce19462764940a4ce99dae4ac2ec7a004c68e9a4/projects.txt#L245-L249" rel="noreferrer" target="_blank">https://github.com/openstack/requirements/blob/ce19462764940a4ce99dae4ac2ec7a004c68e9a4/projects.txt#L245-L249</a><br>
[6] <a href="https://review.rdoproject.org/r/gitweb?p=openstack/tripleo-heat-templates-distgit.git;a=blob;f=openstack-tripleo-heat-templates.spec;h=36ee20fb8042bbdd254b4eab6ab1f3272bd8a6c5;hb=HEAD" rel="noreferrer" target="_blank">https://review.rdoproject.org/r/gitweb?p=openstack/tripleo-heat-templates-distgit.git;a=blob;f=openstack-tripleo-heat-templates.spec;h=36ee20fb8042bbdd254b4eab6ab1f3272bd8a6c5;hb=HEAD</a><br>
[7] <a href="https://github.com/openstack/requirements/blob/f00ad51c3f4de9d956605d81db4ce34fa9a3ba1c/global-requirements.txt#L337" rel="noreferrer" target="_blank">https://github.com/openstack/requirements/blob/f00ad51c3f4de9d956605d81db4ce34fa9a3ba1c/global-requirements.txt#L337</a><br>
<br>
<br>
><br>
> I think we should also plan to backport these changes to Wallaby.<br>
><br>
> Let me know any concerns or feedback, or anything I might be overlooking. Thanks.<br>
><br>
> --<br>
> -- James Slagle<br>
> --<br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Adriano Vieira Petrich</div><div>Software Engineer</div><div>He/Him/His</div><div><br></div><div><pre cols="72" style="white-space:pre-wrap;color:rgb(34,34,34)">Red Hat GmbH, <a href="http://www.de.redhat.com/" style="color:rgb(17,85,204)" target="_blank">https://de.redhat.com/ </a>, Registered seat: Grasbrunn, 
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill </pre></div></div></div>