This was an interesting failure
An update to distributed cloud changed
the minimum version of python-oslo-concurrency
/cgcs-root/stx/distributedcloud/distributedcloud/centos/distributedcloud.spec:BuildRequires:
python-oslo-concurrency >= 3.29.1
A corresponding change was attempted in
...
stx-tools/centos-mirror-tools/config/centos/distro/rpms_centos.lst
-python2-oslo-concurrency-3.27.0-1.el7.noarch.rpm
+python2-oslo-concurrency-3.29.1-1.el7.noarch.rpm
but it was not made in ...
stx-tools/centos-mirror-tools/config/centos/flock/rpms_centos.lst
python2-oslo-concurrency-3.27.0-1.el7.noarch.rpm
The monolithic build was ok, but not
the flock layer build failed. Why?
Distributed cloud builds under the
flock layer. The flock layer build only uses flock layer lst
file. So it needs 3.29.1, but only 3.27.0 is available. Build
fails.
The monolithic build merges the lst
files of all layers. We ended up with two copies of
python2-oslo-concurrency, 3.27.0 and 3.29.1, and the highest
version was used in the build. So all would seem ok if the
designer tested with a monolithic build rather than a flock layer
build.
The monolithic build is going away.
Designers need to do layer builds to
test their changes!
Other thoughts ...
Does python2-oslo-concurrency
need to be listed in two places?
Yes.
There are distro layer components that
BuildRequire python2-oslo-concurrency as well. A distro layer
build would look at
stx-tools/centos-mirror-tools/config/centos/distro/rpms_centos.lst
What if I only upversion the flock
layer and not the distro layer?
While it would have passed build on all
layers, I don't think it's a good idea. The iso is built from the
flock layer, and will use the newer version. The distro layer
packages would have run there tox tests versus an older version of
the library than would be used at runtime. An error that might
have been caught by a unit test will now only be caught at
runtime.
All lst files should agree on the
version to use.
What if the need to upversion was
being driven by a distro layer package? Would I still need to
upversion the flock layer lst file in addition to the distro
layer lst?
Yes.
A package with a 'BuildRequire' on a
newer version will also usually have a 'Require' on the newer
version as well. Updating the distro layer lst will allow the
distro layer build-pkgs to succeed. However, build-iso runs under
the flock layer, only uses the flock layer lst. Omitting the
flock layer lst update will fail on the 'Require' when build-iso
is run.
Project: STX_build_pre_installer_layered
Build #: 53
Status: Failure
Timestamp: 20200224T192300Z
Check logs at:
http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200224T185245Z/logs
--------------------------------------------------------------------------------
Parameters
MY_WORKSPACE: /localdisk/loadbuild/jenkins/master-flock/20200224T185245Z
DOCKER_BUILD_ID: jenkins-master-flock-20200224T185245Z-builder
OS: centos
MY_REPO: /localdisk/designer/jenkins/master-flock/cgcs-root
PUBLISH_LOGS_URL: http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/flock/20200224T185245Z/logs
PUBLISH_LOGS_BASE: /export/mirror/starlingx/master/centos/flock/20200224T185245Z/logs
MASTER_JOB_NAME: STX_build_layer_flock_master_master
LAYER: flock
MY_REPO_ROOT: /localdisk/designer/jenkins/master-flock
BUILD_ISO: true
_______________________________________________
Starlingx-discuss mailing list
Starlingx-discuss@lists.starlingx.io
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss