Open Stack

On Thu, May 13, 2021 at 9:41 PM James Slagle <james.slagle at gmail.com> wrote:
>
> 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.

To add a bit more context as to how this discussion came about, we
tried to remove tripleo-common from global-requirements and the
check-requirements jobs in tripleoclient caused [1] as a result.

So we need to decide whether to continue to be part of that
requirements contract [2] or if we will do what is proposed here and
remove ourselves altogether.
If we decide _not_ to implement this proposal then we will also have
to add the requirements-check jobs in tripleo-ansible [3] and
tripleo-validations [4] as they are currently missing.

>
> 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.

I don't think this is _just_ about pip installs. It is generally about
the contents of each project requirements.txt. As part of the
requirements contract, it means that those repos with which we are
participating (the ones in projects.txt [5]) are protected against
other projects making any breaking changes in _their_
requirements.txt. Don't the contents of requirements.txt also end up
in the .spec file from which we are building rpm e.g. [6] for tht? In
which case if we remove this and just stop catching any breaking
changes in the check/gate check-requirements jobs, I suspect we will
just move the problem to the rpm build and it will fail there.

>
> 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).

I don't think one in particular is a very valid point though - as
things currently stand in global-requirements we aren't 'pinning' all
we have there is "tripleo-common!=11.3.0  # Apache-2.0" [7] to avoid
(I assume) some bad release we made.

One main advantage that isn't mentioned here is that by removing
ourselves from the requirements contract then we are no longer bound
to release tripleo-common first when making a new stable/branch. This
should make it easier to keep gates green on new releases.

>
> The changes needed would be (aiui):
> - Remove tripleo repos from projects.txt
> - Remove check-requirements jobs from those same repos
> - Remove tripleo-common from global-requirements.txt

yes that list looks right if we decide to go ahead with that. As noted
above my main reservation is that we may end up seeing more
incompatibilities in requirements (and later during package building,
instead of earlier during the check/gate check-requirements jobs).

regards, marios

[1] https://bugs.launchpad.net/tripleo/+bug/1928190
[2] https://docs.openstack.org/project-team-guide/dependency-management.html#enforcement-in-projects
[3] https://opendev.org/openstack/tripleo-ansible/src/commit/5b160e8d02acbaaec67df66a5a204e0c0d08366b/zuul.d/layout.yaml#L3
[4] https://opendev.org/openstack/tripleo-validations/src/commit/edf9ee1f34c92e3b8c70bf3d81c72de5ddc7cba0/zuul.d/layout.yaml#L3
[5] https://github.com/openstack/requirements/blob/ce19462764940a4ce99dae4ac2ec7a004c68e9a4/projects.txt#L245-L249
[6] 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
[7] https://github.com/openstack/requirements/blob/f00ad51c3f4de9d956605d81db4ce34fa9a3ba1c/global-requirements.txt#L337


>
> I think we should also plan to backport these changes to Wallaby.
>
> Let me know any concerns or feedback, or anything I might be overlooking. Thanks.
>
> --
> -- James Slagle
> --