Open Stack

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

On Fri, 14 May 2021 at 12:42, 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.
>
> >
> > 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
> > --
>
>
>

-- 
Adriano Vieira Petrich
Software Engineer
He/Him/His

Red Hat GmbH, https://de.redhat.com/  <http://www.de.redhat.com/>,
Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210514/7f99d237/attachment-0001.html>