Open Stack

On Fri, May 14, 2021 at 6:41 AM Marios Andreou <marios at redhat.com> wrote:

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

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?



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

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.

Here's an example:
https://review.opendev.org/c/openstack/python-tripleoclient/+/787907
https://review.opendev.org/c/openstack/tripleo-common/+/787906

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.

-- 
-- James Slagle
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210514/1c0a213c/attachment.html>