[Starlingx-discuss] [build-report] STX_build_pre_installer_layered - Build # 53 - Failure!
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/202002... -------------------------------------------------------------------------------- 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/202002... 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
*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@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/202002... -------------------------------------------------------------------------------- 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/202002... 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
Hi Scott, It's a fantastic sharing and thanks for comprehensive explanation! Inspired by the case here (with 2 versions of python-oslo-concurrency for different layers), I would like to hear your ideas on a similar case (a tech challenge) which we met during CentOS 8 upgrade. Simply we wanted to use new version gcc-8.2.1 for kernel 4.18, and then old version gcc-4.8.5 for user space packages. Is there a way to support this case above under the context of layered build design? We know currently kernel (and out of tree kernel modules) and a set user space packages belong to "disto" layer. But what if we create a new layer for kernel and kernel related modules? Will this make 2 different versions of GCC work for 2 layers? regards, Yong ________________________________ From: Scott Little [scott.little@windriver.com] Sent: Wednesday, February 26, 2020 12:49 AM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Important] STX_build_pre_installer_layered - Build # 53 - Failure! 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@gmail.com<mailto:build.starlingx@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/202002... -------------------------------------------------------------------------------- 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/202002... 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<mailto:Starlingx-discuss@lists.starlingx.io> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
The only way to make this work is to place the kernel and out-of-tree kernel modules into a layer of their own. Scott On 2020-02-25 7:39 p.m., Hu, Yong wrote:
Hi Scott, It's a fantastic sharing and thanks for comprehensive explanation!
Inspired by the case here (with 2 versions of python-oslo-concurrency for different layers), I would like to hear your ideas on a similar case (a tech challenge) which we met during CentOS 8 upgrade. Simply we wanted to use new version gcc-8.2.1 for kernel 4.18, and then old version gcc-4.8.5 for user space packages. Is there a way to support this case above under the context of layered build design? We know currently kernel (and out of tree kernel modules) and a set user space packages belong to "disto" layer. But what if we create a new layer for kernel and kernel related modules? Will this make 2 different versions of GCC work for 2 layers?
regards, Yong ------------------------------------------------------------------------ *From:* Scott Little [scott.little@windriver.com] *Sent:* Wednesday, February 26, 2020 12:49 AM *To:* starlingx-discuss@lists.starlingx.io *Subject:* Re: [Starlingx-discuss] [Important] STX_build_pre_installer_layered - Build # 53 - Failure!
*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@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/202002... -------------------------------------------------------------------------------- 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/202002... 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
participants (3)
-
build.starlingx＠gmail.com
-
Hu, Yong
-
Scott Little