[Starlingx-discuss] [Important] STX_build_pre_installer_layered - Build # 53 - Failure!

[Scott Little]

*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.








On 2020-02-24 2:35 p.m., build.starlingx at gmail.com wrote:
> 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 at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20200225/4c1ac039/attachment-0001.html>