[TripleO] Opting out of global-requirements.txt
apetrich at redhat.com
Fri May 14 11:18:33 UTC 2021
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>
> > 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  as a result.
> So we need to decide whether to continue to be part of that
> requirements contract  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  and
> tripleo-validations  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
> 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 ) 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.  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"  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
>  https://bugs.launchpad.net/tripleo/+bug/1928190
> > 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
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...
More information about the openstack-discuss