[TripleO] Opting out of global-requirements.txt
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. 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. 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). 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 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 --
On Thu, May 13, 2021 at 12:41 PM James Slagle <james.slagle@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.
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.
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).
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
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.
+1 thanks for sending this out James!
-- -- James Slagle --
+1 I 100% agree that we should remove tripleo from global requirements and backport these changes to W. -- Kevin Carter IRC: Cloudnull On Thu, May 13, 2021 at 1:54 PM Wesley Hayutin <whayutin@redhat.com> wrote:
On Thu, May 13, 2021 at 12:41 PM James Slagle <james.slagle@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.
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.
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).
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
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.
+1 thanks for sending this out James!
-- -- James Slagle --
On 13 May 2021, at 19:38, James Slagle <james.slagle@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.
How would this affect the RDO build process? Doesn’t it use a common set of deps defined by global requirements to build everything on a stable branch? Would this mean that TripleO would be built using a different set of deps from the OpenStack services it deploys? I’m all for doing this, but there may be a hidden cost here which needs to be considered.
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.
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.
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).
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
I think it's fine as long as we manage the project requirements properly and ensure that we don't bump to some broken library versions (Tripleo CI may or may not catch those but other projects CIs possibly can), as we sync
On Fri, May 14, 2021 at 12:13 AM James Slagle <james.slagle@gmail.com> wrote: those requirements to rdo spec files regularly.
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 --
-- Regards, Rabi Mishra
On Thu, May 13, 2021 at 9:41 PM James Slagle <james.slagle@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#enf... [3] https://opendev.org/openstack/tripleo-ansible/src/commit/5b160e8d02acbaaec67... [4] https://opendev.org/openstack/tripleo-validations/src/commit/edf9ee1f34c92e3... [5] https://github.com/openstack/requirements/blob/ce19462764940a4ce99dae4ac2ec7... [6] https://review.rdoproject.org/r/gitweb?p=openstack/tripleo-heat-templates-di... [7] https://github.com/openstack/requirements/blob/f00ad51c3f4de9d956605d81db4ce...
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 --
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@redhat.com> wrote:
On Thu, May 13, 2021 at 9:41 PM James Slagle <james.slagle@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#enf... [3] https://opendev.org/openstack/tripleo-ansible/src/commit/5b160e8d02acbaaec67... [4] https://opendev.org/openstack/tripleo-validations/src/commit/edf9ee1f34c92e3... [5] https://github.com/openstack/requirements/blob/ce19462764940a4ce99dae4ac2ec7... [6] https://review.rdoproject.org/r/gitweb?p=openstack/tripleo-heat-templates-di... [7] https://github.com/openstack/requirements/blob/f00ad51c3f4de9d956605d81db4ce...
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
On Fri, May 14, 2021 at 6:41 AM Marios Andreou <marios@redhat.com> wrote:
On Thu, May 13, 2021 at 9:41 PM James Slagle <james.slagle@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 --
On Fri, May 14, 2021 at 4:28 PM James Slagle <james.slagle@gmail.com> wrote:
On Fri, May 14, 2021 at 6:41 AM Marios Andreou <marios@redhat.com> wrote:
On Thu, May 13, 2021 at 9:41 PM James Slagle <james.slagle@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?
I was looking at that in particular: "tripleo-common>=7.1.0 # Apache-2.0" at https://opendev.org/openstack/tripleo-heat-templates/src/commit/fe2373225f03... and in the specfile: " 42 Requires: openstack-tripleo-common >= 7.1.0" at https://review.rdoproject.org/r/gitweb?p=openstack/tripleo-heat-templates-di... I assumed there was correlation there with the value originally coming from the project requirements.txt - but perhaps that is wrong; I realise now that the specfile is referencing 'openstack-tripleo-common' the built rpm, not 'tripleo-common'. Well OK, that was/is my biggest concern; i.e. we are getting value from having this requirements compatibility check, and if we remove it we will just end up having those compatibility problems further down the chain. On the flip side, it just doesn't seem to me to be that big a cost for us to stay inside this check. We aren't running check-requirements job on every posted change it is only ever triggered if you submit a change to requirements.txt https://opendev.org/openstack/requirements/src/commit/ce19462764940a4ce99dae... .
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.
ack I see what you mean now about pip install => tagged release vs dlrn current => git master/latest commit and also agree that is not directly related to this discussion about the check-requirements jobs. regards, marios
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 --
On Fri, May 14, 2021 at 6:41 AM Marios Andreou < marios@redhat.com > wrote:
On Thu, May 13, 2021 at 9:41 PM James Slagle < james.slagle@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?
We run periodic syncs once every cycle, and try our best to make spec requirements match requirements.txt/test-requirements.txt for the project. See https://review.rdoproject.org/r/c/openstack/tripleoclient-distgit/+/33367 for a recent example on tripleoclient. I don't have a special opinion on keeping tripleo-common inside global-requirements.txt or not. However, all TripleO projects still need to be co-installable with other OpenStack projects, otherwise we will not be able to build packages for them due to all the dependency issues that could arise. I'm not sure if that was implied in the original post. Regards, Javier
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 --
On Fri, May 14, 2021 at 9:07 PM Javier Pena <jpena@redhat.com> wrote:
On Fri, May 14, 2021 at 6:41 AM Marios Andreou <marios@redhat.com> wrote:
On Thu, May 13, 2021 at 9:41 PM James Slagle <james.slagle@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?
We run periodic syncs once every cycle, and try our best to make spec requirements match requirements.txt/test-requirements.txt for the project. See https://review.rdoproject.org/r/c/openstack/tripleoclient-distgit/+/33367 for a recent example on tripleoclient.
I don't have a special opinion on keeping tripleo-common inside global-requirements.txt or not. However, all TripleO projects still need to be co-installable with other OpenStack projects, otherwise we will not be able to build packages for them due to all the dependency issues that could arise.
I think this is probably less of an issue with containerized services(?). At present, there are only two service containers that install tripleo-common (mistral, nova-scheduler). With mistral deprecated and nova removed from the undercloud (tripleo-common has a tripleo specific scheduler filter used by undercloud nova), we probably won't have many issues. However, as we sync requirements from project requirements to package specs regularly, there could be issues with broken requirements.
I'm not sure if that was implied in the original post.
Regards, Javier
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 --
-- Regards, Rabi Mishra
Hi, I didn't really want to get into this, but we (VF squad) have recently encountered an issue that might provide some context to this discussion. Due to omission on my part, we have been building pdf documentation for validations-common without querying openstack/requirements upper-constrainst. This meant that we were always pulling the newest version of packages, and as the job was triggered only rarely, we didn't see the problem until promotes began to fail. A new version of one of our dependencies (I believe it was sphinx) introduced, by proxy, dependency on the "tgtermes.sty" style file. Lack of upper constraints made the issue harder to diagnose, as the version of packages to installed changed, depending on their relative dependencies and continuous updates. With several dozen packages, there is considerable chance of one getting a version bump every week or so. Which brings me to my point. The openstack/requirements does provide one rather essential service for us. In the form of upper-constraints for our pip builds. While we are mostly installing software through rpm, many CI jobs use pip in some fashion. Without upper constraints, pip pulls aggressively the newest version available and compatible with other packages. Which causes several issues, noted by even pip people. There is also a question of security. There is a possibility of a bad actor introducing a package with an extremely high version number. Such a package would get precedence over the legitimate releases. In fact, just this sort of attack was spotted in the wild.[1] Now, nothing is preventing us from using upper requirements, without being in the openstack/requirements projects. On the other hand, if we remove ourselves from the covenant, nothing is stopping the openstack/requirements people from changing versions of the accepted packages without considering the impact it could have on our projects. I believe this is something we need to consider. [1] (https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610) On Mon, May 17, 2021 at 8:55 AM Rabi Mishra <ramishra@redhat.com> wrote:
On Fri, May 14, 2021 at 9:07 PM Javier Pena <jpena@redhat.com> wrote:
On Fri, May 14, 2021 at 6:41 AM Marios Andreou <marios@redhat.com> wrote:
On Thu, May 13, 2021 at 9:41 PM James Slagle <james.slagle@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?
We run periodic syncs once every cycle, and try our best to make spec requirements match requirements.txt/test-requirements.txt for the project. See https://review.rdoproject.org/r/c/openstack/tripleoclient-distgit/+/33367 for a recent example on tripleoclient.
I don't have a special opinion on keeping tripleo-common inside global-requirements.txt or not. However, all TripleO projects still need to be co-installable with other OpenStack projects, otherwise we will not be able to build packages for them due to all the dependency issues that could arise.
I think this is probably less of an issue with containerized services(?). At present, there are only two service containers that install tripleo-common (mistral, nova-scheduler). With mistral deprecated and nova removed from the undercloud (tripleo-common has a tripleo specific scheduler filter used by undercloud nova), we probably won't have many issues.
However, as we sync requirements from project requirements to package specs regularly, there could be issues with broken requirements.
I'm not sure if that was implied in the original post.
Regards, Javier
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 --
-- Regards, Rabi Mishra
On Wed, May 19, 2021 at 4:07 AM Jiri Podivin <jpodivin@redhat.com> wrote:
Which brings me to my point. The openstack/requirements does provide one rather essential service for us. In the form of upper-constraints for our pip builds. While we are mostly installing software through rpm, many CI jobs use pip in some fashion. Without upper constraints, pip pulls aggressively the newest version available and compatible with other packages. Which causes several issues, noted by even pip people.
There is also a question of security. There is a possibility of a bad actor introducing a package with an extremely high version number. Such a package would get precedence over the legitimate releases. In fact, just this sort of attack was spotted in the wild.[1]
It should be noted however that upper-constraints.txt only applies in CI. If you "pip install python-tripleoclient" in a fresh virtualenv, you get latest releases, assuming they satisfy other dependencies.
Now, nothing is preventing us from using upper requirements, without being in the openstack/requirements projects. On the other hand, if we remove ourselves from the covenant, nothing is stopping the openstack/requirements people from changing versions of the accepted packages without considering the impact it could have on our projects.
This would mean you could potentially have issues pip installing with the rest of OpenStack that have accepted the requirements contract. It goes back to my original point that I don't think we care. Overall, I don't get the sense there is broad agreement about this change, and it is not completely understood, myself included here. We should likely hold off on making any decisions until time allows for a more thorough deep dive into the implications. In the meantime however, I do think tripleo-validations needs the check-requirements job added since it depends on tripleo-common (in g-r) and tripleo-validations is itself in projects.txt. -- -- James Slagle --
In the meantime however, I do think tripleo-validations needs the check-requirements job added since it depends on tripleo-common (in g-r) and tripleo-validations is itself in projects.txt.
Good point. I'm going to submit it today. On Fri, May 21, 2021 at 3:57 PM James Slagle <james.slagle@gmail.com> wrote:
On Wed, May 19, 2021 at 4:07 AM Jiri Podivin <jpodivin@redhat.com> wrote:
Which brings me to my point. The openstack/requirements does provide one rather essential service for us. In the form of upper-constraints for our pip builds. While we are mostly installing software through rpm, many CI jobs use pip in some fashion. Without upper constraints, pip pulls aggressively the newest version available and compatible with other packages. Which causes several issues, noted by even pip people.
There is also a question of security. There is a possibility of a bad actor introducing a package with an extremely high version number. Such a package would get precedence over the legitimate releases. In fact, just this sort of attack was spotted in the wild.[1]
It should be noted however that upper-constraints.txt only applies in CI. If you "pip install python-tripleoclient" in a fresh virtualenv, you get latest releases, assuming they satisfy other dependencies.
Now, nothing is preventing us from using upper requirements, without being in the openstack/requirements projects. On the other hand, if we remove ourselves from the covenant, nothing is stopping the openstack/requirements people from changing versions of the accepted packages without considering the impact it could have on our projects.
This would mean you could potentially have issues pip installing with the rest of OpenStack that have accepted the requirements contract. It goes back to my original point that I don't think we care.
Overall, I don't get the sense there is broad agreement about this change, and it is not completely understood, myself included here. We should likely hold off on making any decisions until time allows for a more thorough deep dive into the implications.
In the meantime however, I do think tripleo-validations needs the check-requirements job added since it depends on tripleo-common (in g-r) and tripleo-validations is itself in projects.txt.
-- -- James Slagle --
On Fri, May 21, 2021 at 6:04 PM Jiri Podivin <jpodivin@redhat.com> wrote:
In the meantime however, I do think tripleo-validations needs the check-requirements job added since it depends on tripleo-common (in g-r) and tripleo-validations is itself in projects.txt.
Good point. I'm going to submit it today.
On Fri, May 21, 2021 at 3:57 PM James Slagle <james.slagle@gmail.com> wrote:
On Wed, May 19, 2021 at 4:07 AM Jiri Podivin <jpodivin@redhat.com> wrote:
Which brings me to my point. The openstack/requirements does provide one rather essential service for us. In the form of upper-constraints for our pip builds. While we are mostly installing software through rpm, many CI jobs use pip in some fashion. Without upper constraints, pip pulls aggressively the newest version available and compatible with other packages. Which causes several issues, noted by even pip people.
There is also a question of security. There is a possibility of a bad actor introducing a package with an extremely high version number. Such a package would get precedence over the legitimate releases. In fact, just this sort of attack was spotted in the wild.[1]
It should be noted however that upper-constraints.txt only applies in CI. If you "pip install python-tripleoclient" in a fresh virtualenv, you get latest releases, assuming they satisfy other dependencies.
Now, nothing is preventing us from using upper requirements, without being in the openstack/requirements projects. On the other hand, if we remove ourselves from the covenant, nothing is stopping the openstack/requirements people from changing versions of the accepted packages without considering the impact it could have on our projects.
This would mean you could potentially have issues pip installing with the rest of OpenStack that have accepted the requirements contract. It goes back to my original point that I don't think we care.
Overall, I don't get the sense there is broad agreement about this change, and it is not completely understood, myself included here. We should likely hold off on making any decisions until time allows for a more thorough deep dive into the implications.
In the meantime however, I do think tripleo-validations needs the check-requirements job added since it depends on tripleo-common (in g-r) and tripleo-validations is itself in projects.txt
yeah I brought this up in my earlier reply if we're not removing (and seems like we aren't for now) then we need to add coverage in tripleo-validations and tripleo-ansible which is posted there https://review.opendev.org/c/openstack/tripleo-ansible/+/792830 regards, marios
-- -- James Slagle --
participants (9)
-
Adriano Petrich
-
Carter, Kevin
-
James Slagle
-
Javier Pena
-
Jesse Pretorius
-
Jiri Podivin
-
Marios Andreou
-
Rabi Mishra
-
Wesley Hayutin