Andreas Jaeger <a...@suse.com> wrote:
TL;DR: Projects can use bindep.txt to document in a programmatic way
their binary dependencies
Python developers record their dependencies on other Python packages in
requirements.txt and test-requirements.txt. But some packages
havedependencies outside of python and we should document
thesedependencies as well so that operators, developers, and CI systems
know what needs to be available for their programs.
Bindep is a solution to this, it allows a repo to document
binarydependencies in a single file. It even enablies specification of
which distribution the package belongs to - Debian, Fedora, Gentoo,
openSUSE, RHEL, SLES and Ubuntu have different package names - and
allows profiles, like a test profile.
Bindep is one of the tools the OpenStack Infrastructure team has written
and maintains. It is in use by already over 130 repositories.
For better bindep adoption, in the just released bindep 2.1.0 we have
changed the name of the default file used by bindep from
other-requirements.txt to bindep.txt and have pushed changes [3] to
master branches of repositories for this.
Projects are encouraged to create their own bindep files. Besides
documenting what is required, it also gives a speedup in running tests
since you install only what you need and not all packages that some
other project might need and are installed by default. Each test system
comes with a basic installation and then we either add the repo defined
package list or the large default list.
In the OpenStack CI infrastructure, we use the "test" profile for
installation of packages. This allows projects to document their run
time dependencies - the default packages - and the additional packages
needed for testing.
Be aware that bindep is not used by devstack based tests, those have
their own way to document dependencies.
A side effect is that your tests run faster, they have less packages to
install. A Ubuntu Xenial test node installs 140 packages and that can
take between 2 and 5 minutes. With a smaller bindep file, this can change.
Let's look at the log file for a normal installation with using the
default dependencies:
2 upgraded, 139 newly installed, 0 to remove and 41 not upgraded
Need to get 148 MB of archives.
After this operation, 665 MB of additional disk space will be used.
Compare this with the openstack-manuals repostiry that uses bindep -
this example was 20 seconds and not minutes:
0 upgraded, 17 newly installed, 0 to remove and 43 not upgraded.
Need to get 35.8 MB of archives.
After this operation, 128 MB of additional disk space will be used.
If you want to learn more about bindep, read the Infra Manual on package
requirements [1] or the bindep manual [2].
If you have further questions about bindep, feel free to ask the Infra
team on #openstack-infra.
Thanks to Anita for reviewing and improving this blog post and to the
OpenStack Infra team that maintains bindep, especially to Jeremy Stanley
and Robert Collins.
Note I'm sending this out while not all our test clouds have images that
know about bindep.txt (they only handle other-requirements.txt). The
infra team is in the process of ensuring updated images in all our test
clouds for later today. Thanks, Paul!
Andreas
References:
[1]
http://docs.openstack.org/infra/manual/drivers.html#package-requirements
[2] http://docs.openstack.org/infra/bindep/
[3] https://review.openstack.org/#/q/branch:master+topic:bindep-mv
—
I went and sent a strawman patch for neutron to adopt bindep.txt:
https://review.openstack.org/#/c/381906/
When I execute 'bindep test’ locally, I get the following error on
centos7.2 which is expected:
Bad versions of installed packages:
sqlite version 3.7.17-8.el7 does not match >=3.8
I would think that this output is passed to apt-get in the gate. But then I
see the following failure in gate:
http://logs.openstack.org/06/381906/3/check/gate-neutron-pep8-ubuntu-xenial/148dcd8/console.html#_2016-10-04_15_57_36_846699
Apparently, bindep tool failed to parse the file on that other platform?
Can anyone help me to understand what I’m missing?
Ihar
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
