[Starlingx-discuss] FW: [Build] Build layering reviews

Saul Wold sgw at linux.intel.com
Tue Oct 15 16:15:47 UTC 2019


I am wondering if it would be easier to test and review this if we had 
all these changes on a branch and have an associated manifest.

Sau!


On 10/15/19 7:27 AM, Chen, Haochuan Z wrote:
> Hi
> 
> I have updated patch for layer build
> 
> https://review.opendev.org/#/c/681821/
> 
> https://review.opendev.org/#/c/681823/
> 
> https://review.opendev.org/#/c/681824/
> 
> https://review.opendev.org/#/c/681828/
> 
> https://review.opendev.org/#/c/681832/
> 
> https://review.opendev.org/#/c/681834/
> 
> https://review.opendev.org/#/c/681835/
> 
> https://review.opendev.org/#/c/681836/
> 
> https://review.opendev.org/#/c/681842/
> 
> https://review.opendev.org/#/c/681847/
> 
> https://review.opendev.org/#/c/681848/
> 
> https://review.opendev.org/#/c/681851/
> 
> https://review.opendev.org/#/c/681852/
> 
> https://review.opendev.org/#/c/681854/
> 
> https://review.opendev.org/#/c/681856/
> 
> https://review.opendev.org/#/c/681890/
> 
> https://review.opendev.org/#/c/681892/
> 
> https://review.opendev.org/#/c/681894/
> 
> https://review.opendev.org/#/c/681898/
> 
> https://review.opendev.org/#/c/681900/
> 
> https://review.opendev.org/#/c/681901/
> 
> https://review.opendev.org/#/c/681902/
> 
> https://review.opendev.org/#/c/681914/
> 
> https://review.opendev.org/#/c/688598/
> 
> And I think we still left three issue.
> 
> 1, request build-tools/build_iso/centos_required_build_layer.cfg
> 
> Current for self validation, we could add a file with such content. But 
> we should create a file depending on cenga update
> 
> compile,file:///localdisk/loadbuild/martin/starlingx/centos_compile_iso_image.inc
> 
> distro,file:///localdisk/loadbuild/martin/distro/centos_distro_iso_image.inc
> 
> flock,file:///localdisk/loadbuild/martin/flock/centos_flock_iso_image.inc
> 
> 2, propose use one copy of yum.conf.sample and yum.repo.d/*
> 
> Currently there is 4 copies of yum.conf.sample and yum.repo.d/*.  3 
> copies in stx-tools/centos-mirror-tools/config/centos/<layer>/ and 1 
> copy in stx-tools/centos-mirror-tools/
> 
>    Propose to remove 3 copies in 
> stx-tools/centos-mirror-tools/config/centos/<layer>/. To avoid user 
> confusing
> 
> 3, update script download_mirror.sh and generate-cgts-centos-repo
> 
> Currently all rpm name in lst is listed with fixed rpm version, which 
> makes layer build easily to be corrupted. For example, any time 
> TIS_PATCH_VER in build_srpm.data update, rpm name in lst should be updated.
> 
> Prefer rpm named with “tis” should be query candidate on cenga, which 
> request download_mirror.sh and generate-cgts-centos-repo update. Prefer 
> we could finish such update in this story, as I think this is a critical 
> issue.
> 
> Thanks!
> 
> Martin, Chen
> 
> SSP, Software Engineer
> 
> 021-61164330
> 
> *From:*Penney, Don <Don.Penney at windriver.com>
> *Sent:* Monday, September 30, 2019 11:33 PM
> *To:* Bailey, Henry Albert (Al) <Al.Bailey at windriver.com>; Chen, 
> Haochuan Z <haochuan.z.chen at intel.com>; Little, Scott 
> <Scott.Little at windriver.com>; 'starlingx-discuss at lists.starlingx.io' 
> <starlingx-discuss at lists.starlingx.io>
> *Subject:* RE: [Starlingx-discuss] FW: [Build] Build layering reviews
> 
> Is this the issue?
> 
> openstack/python-horizon/centos/python-django-horizon.spec:BuildRequires: cgts-client
> 
> I don’t see anything in this package that should need this dependency, 
> and it should be safe to remove it.
> 
> *From:*Bailey, Henry Albert (Al) [mailto:Al.Bailey at windriver.com]
> *Sent:* Monday, September 30, 2019 10:56 AM
> *To:* Chen, Haochuan Z; Little, Scott; 
> 'starlingx-discuss at lists.starlingx.io'
> *Subject:* Re: [Starlingx-discuss] FW: [Build] Build layering reviews
> 
> I think Cgts-client  (renamed to system-client)  should be in its own repo.
> 
> Al
> 
> *From:*Chen, Haochuan Z [mailto:haochuan.z.chen at intel.com]
> *Sent:* Monday, September 30, 2019 2:06 AM
> *To:* Little, Scott; 'starlingx-discuss at lists.starlingx.io'
> *Subject:* Re: [Starlingx-discuss] FW: [Build] Build layering reviews
> 
> Hi Scott
> 
> I think have some question or concern.
> 
> 1, I find distro layer has dependency to cgts-client, as there is a 
> addin for Horizon, which enables look up flock service info in Horizon.
> 
> So there is task is must for layer building, which is out of my 
> expectation.  I begin to tackle these task.
> 
> ·Relocate from git 'config', subdir 'sysinv/cgts-client', to git 
> 'utilities', subdir 'system-client', *with full git history.*
> 
> ·Rename rpm package from 'cgts-client' to 'system-client'
> 
> ·Fix rpm packages that list cgts-client as a require or build require
> 
> ·Rename python module from 'cgts-client' to 'system-client'
> 
> ·Scan function names and/or variables for any that contain 'cgts' ... 
> replace with 'system' ... can we do this in a backward compatible way?
> 
> ·Fix users of the client to import using the new name, and reference any 
> renamed functions/data.
> 
> ·Fix ISO and/or docker images that list this package for inclusion.
> 
> 2, “all” layer maybe doesn’t work, warning!
> 
> For current patch for generate-cgts-centos-repo.sh, all layer’s 
> rpms_lst_file is generated by merge “compiler/distro/flock” three 
> layers, config/centos/all doesn’t be referenced, which is none sense. 
> Which means package such bash-4.2.46-31.el7.tis.4.x86_64.rpm, named with 
> “tis” is also in mirror. This maybe interference source package 
> building. I think request some fix in generate-cgts-centos-repo.sh to 
> omit package with “tis” in name.
> 
> 3, Layered build introduces rpms_cemtos.lst dependency on TIS_PATCH_VER 
> in build_srpm.data, which make developer easily disrupt layered building 
> mechanism.
> 
> For distro and flock layer, it has dependency to starlingX customized 
> package, for example, distro layer require bash.tis.<tis patch 
> version>.<version>.rpm, which will be add in 
> config/centos/distro/rpms_centos3rdparty.lst
> 
> If new developer forget to update and build all package, it maybe 
> disrupt layered building.
> 
> BR!
> 
> Martin, Chen
> 
> SSP, Software Engineer
> 
> 021-61164330
> 
> *From:*Chen, Haochuan Z
> *Sent:* Friday, September 27, 2019 4:40 PM
> *To:* Scott Little <scott.little at windriver.com 
> <mailto:scott.little at windriver.com>>; 
> starlingx-discuss at lists.starlingx.io 
> <mailto:starlingx-discuss at lists.starlingx.io>
> *Subject:* RE: FW: [Starlingx-discuss] [Build] Build layering reviews
> 
> Thanks, Scott. I have studied so much.
> 
> BR!
> 
> Martin, Chen
> 
> SSP, Software Engineer
> 
> 021-61164330
> 
> *From:*Scott Little <scott.little at windriver.com 
> <mailto:scott.little at windriver.com>>
> *Sent:* Thursday, September 26, 2019 11:39 PM
> *To:* Chen, Haochuan Z <haochuan.z.chen at intel.com 
> <mailto:haochuan.z.chen at intel.com>>; 
> starlingx-discuss at lists.starlingx.io 
> <mailto:starlingx-discuss at lists.starlingx.io>
> *Subject:* Re: FW: [Starlingx-discuss] [Build] Build layering reviews
> 
> Returning this discussion to the mailing list.
> 
> If possible, join the Build call next week. 
> https://wiki.openstack.org/wiki/Starlingx/Meetings
> 
> 1)
> 
> When mock installs for the first time. it uses rpms that have been 
> download via lst file. The mock pseudo-layer lst files capture reflect 
> the rpms needed by mock.  The mock lst's are merged with the layers 
> lst's.  In this way, the mock rpms don't have to be listed in each and 
> every layer's lst.
> 
> 2)
> 
> Adding tools to generate an lst file reflacting the output of a build  
> layer, and adding that lst for consumprion by higher layers, is indeed a 
> possibility possibility I wanted to persue.  Reference to that output 
> lst could then be added to as a new arg to the download script when 
> invoked by a higher layer, or a config file could specify where to find 
> it (cengn is the likely default supplier).
> 
> compile layer)
> 
> The compile layer is a true layer, built prior to the distro layer.  
> Only a few build related packages go here.  Compilers, language 
> interpreters, rpm.  I wanted those packages in place so that all distro 
> layer packages build with the same tools.
> 
> Scott
> 
> On 2019-09-25 10:24 p.m., Chen, Haochuan Z wrote:
> 
>     Still not clear about mock layer.
> 
>     1, In build container, mock is already installed, why request to
>     download mock required package firstly?
> 
>     2, To build distro or flock layer, we could add compile layer’s tis
>     rpm in distro and flock layer’s lst file. By download compile
>     layer’s binary in mirror, it could also ensure user building package
>     with same tool.
> 
>     Why introduces compile layer?
> 
>     Thanks!
> 
>     Martin, Chen
> 
>     SSP, Software Engineer
> 
>     021-61164330
> 
>     *From:*Scott Little <scott.little at windriver.com>
>     <mailto:scott.little at windriver.com>
>     *Sent:* Thursday, September 26, 2019 12:25 AM
>     *To:* Chen, Haochuan Z <haochuan.z.chen at intel.com>
>     <mailto:haochuan.z.chen at intel.com>
>     *Subject:* Re: FW: [Starlingx-discuss] [Build] Build layering reviews
> 
>     See inline ...
> 
>     Scott
> 
>     On 2019-09-23 11:00 a.m., Chen, Haochuan Z wrote:
> 
>         Hi Scott
> 
>         I studied your patch and some questions.
> 
>         1, why there is mock and compile layer, what's usage or
>         intention for these two layers?
> 
>     Build-pkgs uses a tool called mock to create a reproducible
>     compilation sandbox.  It is chroot like environmnet into which rpms
>     are installed to construct a minimal build environment.
> 
>     The mock layer is not built.  I created it as a placeholder for the
>     lst files that downloads all the rpms that mock requires.  Prior to
>     building a layer, the lst files for both the layer being build, and
>     the mock pseudo layer, need to be processed. Without the mock pseudo
>     layer, we would have to replicate that list of mock required rpms in
>     each and ever layer's lst files.
> 
>     The concept ran into a bit of trouble because some of the rpms
>     needed by mock are themselves built by the compile or distro layers
>     (with a newer revision).   So the
>     mock pseudo layer might actually omit those rpms from it's lst file,
>     and they needed to be listed in the layer lst files instead.
> 
>     The compile layer is a true layer, built prior to the distro layer. 
>     Only a few build related packages go here.  Compilers, language
>     interpreters, rpm.  I wanted those packages in place so that all
>     distro layer packages build with the same tools.
> 
>         2, for download_mirror.sh, it generate rpm list by merge file in
>         config/centos/<layer>/<rpm list file name> and rpm list file in
>         stx/<project name>
> 
>             But for generate-cgcs-centos-repo.sh, it use rpm list file
>         in centos-mirror-tools folder. Rpm package should be added in
>         two rpm list file.
> 
>             It is not good for maintenance. What about remove rpm list
>         file in centos-mirror-tools folder
> 
>         /rpms_centos.lst/rpms_centos3rdparties.lst/rpms_3rdparties.lst/other_downloads.lst/
>         tarball-dl.lst/
> 
>     That was considered and debated. The concern was that the many git
>     repos that make up the layer would list different versions of the
>     same package.  Then what do we do?  Throw an error?  Silently use
>     the newest package?  So we elected to keep binary rpms needed to
>     satisfy dependencies listed in a central place.
> 
>     At some point we may want to explore allowing lst files specify
>     required package but not version (beyond a possible minimum version)
>     when on the master branch, and have a way to 'lock down' the
>     versions only for a release branch.
> 
>         3, Question about setup yum repo for rpm tailing with “tis” such
>         as xxx.*tis*.x86_64.rpm or xxx.*tis*.noarch.rpm
> 
>         In this patch https://review.opendev.org/#/c/681821/1
> 
>         /There is such line in
>         config/centos/flock/yum.repos.d/StarlingX_cengn_distro_layer.repo/
> 
>         /[Starlingx-cengn_distro_layer]/
> 
>         /name=Starlingx-cengn_distro_layer/
> 
>         /baseurl=http://127.0.0.1:8088/localdisk/loadbuild//*/slittle1/restructure3b/*//std/rpmbuild/RPMS//
> 
>         /enabled=1/
> 
>         /[Starlingx-cengn_distro_layer-rt]/
> 
>         /name=Starlingx-cengn_distro_layer/
> 
>         /baseurl=http://127.0.0.1:8088/localdisk/loadbuild//*/slittle1/restructure3b/*//rt/rpmbuild/RPMS//
> 
>         /enabled=1/
> 
>         also in
> 
>         config/centos/flock/yum.repos.d/StarlingX_cengn_compile_layer.repo
> 
>         config/centos/distro/yum.repos.d/StarlingX_cengn_compile_layer.repo
> 
>         My understanding is rpm tailing with “tis” should also upload to
>         cengn, rpm name listed in
>         centos-mirror-tools/config/centos/flock/rpms_centos3rdparties.lst
> 
>         So these three files should be unnecessary, with cengn update
>         for layered build.
> 
>         config/centos/flock/yum.repos.d/StarlingX_cengn_distro_layer.repo
> 
>         config/centos/flock/yum.repos.d/StarlingX_cengn_compile_layer.repo
> 
>         config/centos/distro/yum.repos.d/StarlingX_cengn_compile_layer.repo
> 
>     For development testing, I had to hack together a simulated cengn by
>     running lighttpd on 127.0.0.1:8088 and allowing it to serve up files
>     from builds of lower layers
> 
>     restructure3a == layer-comiler layer build
> 
>     restructure3b == layer-distro layer build
> 
>     restructure3c == layer-flock layer build  (although there shouldn't
>     be a repo entry referring to that one)
> 
>     Finalizing the repo entries would have to wait until cengn was up an
>     running.
> 
>         4, In generate-cgcs-centos-repo.sh there is --layer-dir, and
>         such content in your patch commit message
> 
>         /generate-cgcs-centos-repo.sh \/
> 
>         /--layer-dir=/localdisk/loadbuild/slittle1/layer-compile/std/rpmbuild/RPMS/
>         \/
> 
>         /--layer-dir=/localdisk/loadbuild/slittle1/layer-distro/std/rpmbuild/RPMS/
>         \/
> 
>         /--layer-dir=/localdisk/loadbuild/slittle1/layer-distro/rt/rpmbuild/RPMS/
>         \/
> 
>         //import/mirrors/starlingx/
> 
>             For all rpm download from cengn, --layer-dir is unnecessary
>         to generate link, correct?
> 
>     This is another way to do cross layer development testing without
>     support from cengn.  Again the goal is to allow an upper layer build
>     to download rpms from a lower layer build on the same machine.
> 
>         5, could you share
>         build-tools/build-iso/centos_required_build_layer.cfg, share to me
> 
>     Did that not get published in my reviews?  Content is very simple.
> 
>     compile,file:///localdisk/loadbuild/slittle1/restructure3a/centos_compile_iso_image.inc
>     <file://localdisk/loadbuild/slittle1/restructure3a/centos_compile_iso_image.inc>
>     distro,file:///localdisk/loadbuild/slittle1/restructure3b/centos_distro_iso_image.inc
>     <file://localdisk/loadbuild/slittle1/restructure3b/centos_distro_iso_image.inc>
>     flock,file:///localdisk/loadbuild/slittle1/restructure3c/centos_flock_iso_image.inc
>     <file://localdisk/loadbuild/slittle1/restructure3c/centos_flock_iso_image.inc>
> 
>         6, For distro/compiler/flock, all are separate layer?
> 
>     Yes
> 
>         My current step
> 
>         /repo init -u https://opendev.org/starlingx/manifest.git/
> 
>         /apply this patch to .repo/manifests/
> 
>         /https://review.opendev.org/#/c/681914/1/
> 
>         /repo init -m compile.xml/
> 
>         /repo sync/
> 
>         /apply these to patch/
> 
>         /https://review.opendev.org/#/c/681821/1/
> 
>         /https://review.opendev.org/#/c/681828/1/
> 
>         /./download_mirror.sh  -n -g -l flock -c
>         config/centos/compiler/yum.conf.sample -S /
> 
>         /./toCopy/generate-cgts-centos-repo output/stx-r1/CentOS/pike//
> 
>         /build-pkgs/
> 
>         /build-iso/
> 
>         BR!
> 
>         Martin, Chen
> 
>         SSP, Software Engineer
> 
>         021-61164330
> 
>         -----Original Message-----
>         From: Scott Little <scott.little at windriver.com>
>         <mailto:scott.little at windriver.com>
>         Sent: Thursday, September 19, 2019 9:54 PM
>         To: Chen, Haochuan Z <haochuan.z.chen at intel.com>
>         <mailto:haochuan.z.chen at intel.com>
>         Subject: Re: FW: [Starlingx-discuss] [Build] Build layering reviews
> 
>         Most of the required changes were already merged.
> 
>         I'll scan the spec when time permits to see if I missed anything.
> 
>         Scott
> 
>         On 2019-09-16 12:01 p.m., Chen, Haochuan Z wrote:
> 
>          > Hi Scott
> 
>          >
> 
>          > I read your patch for build layering, but could not find
>         patch for build script.
> 
>          >
> 
>          > Description in spec https://review.opendev.org/#/c/672288/12/
> 
>          > Modifications to package build scripts ... build-pkgs,
> 
>          > build-srpms-parallel, build-srpms-serial,
>         build-rpms-parallel, build-rpms-serial (cgcs-root):
> 
>          >
> 
>          > Thanks
> 
>          >
> 
>          > Martin, Chen
> 
>          > SSP, Software Engineer
> 
>          > 021-61164330
> 
>          >
> 
>          > -----Original Message-----
> 
>          > From: Xie, Cindy
> 
>          > Sent: Friday, September 13, 2019 12:24 PM
> 
>          > To: Chen, Haochuan Z <haochuan.z.chen at intel.com
>         <mailto:haochuan.z.chen at intel.com>>
> 
>          > Cc: Hu, Yong <yong.hu at intel.com <mailto:yong.hu at intel.com>>
> 
>          > Subject: FW: [Starlingx-discuss] [Build] Build layering reviews
> 
>          >
> 
>          > Martin,
> 
>          > I am wondering if you will be interested to working on this
>         task. To me, having layering build and provide efficiency to
>         developers are very important for StarlingX. It also provide a
>         chance that you and work together w/ WR folks being more close
>         collaboration. Let me know your interested level.
> 
>          >
> 
>          > Thx. -cindy
> 
>          >
> 
>          > -----Original Message-----
> 
>          > From: Scott Little <scott.little at windriver.com
>         <mailto:scott.little at windriver.com>>
> 
>          > Sent: Friday, September 13, 2019 4:55 AM
> 
>          > To: starlingx-discuss at lists.starlingx.io
>         <mailto:starlingx-discuss at lists.starlingx.io>
> 
>          > Subject: [Starlingx-discuss] [Build] Build layering reviews
> 
>          >
> 
>          > My prototype code for the layered build has been posted to
>         gerrit.
> 
>          > (listed below)
> 
>          >
> 
>          > I was briefly able to build all layers, and produce an iso
>         with the same package content as the cengn build.  Then I was
>         diverted by non-trivial changes to the restructuring work. What
>         I have posted is now several weeks out of date and will almost
>         certainly will not work.  The devil is in keeping the lst files
>         in sync with the ever changing master branch.
> 
>          >
> 
>          > Other commitments will prevent me from resuming this work
>         until November.  If anyone wants to whip the lst files into
>         shape and try to get the build working again, be my guest.
> 
>          >
> 
>          > Final delivery will require changes to the CENGN build
>         scripts (Don or Myself), and a freeze on packaging changes will
>         likely be required for aprox 3 days to finalize the lst files.
> 
>          >
> 
>          > Scott
> 
>          >
> 
>          > ---------------- <Snip> ----------------
> 
>          >
> 
>          > https://review.opendev.org/#/c/681821/1
> 
>          >
> 
>          > https://review.opendev.org/#/c/681914/1
> 
>          >
> 
>          > https://review.opendev.org/#/c/681823/1
> 
>          >
> 
>          > https://review.opendev.org/#/c/681824/1
> 
>          >
> 
>          > https://review.opendev.org/#/c/681828/1
> 
>          >
> 
>          > https://review.opendev.org/#/c/681832/2
> 
>          >
> 
>          > https://review.opendev.org/#/c/681834/1
> 
>          >
> 
>          > https://review.opendev.org/#/c/681836/1
> 
>          >
> 
>          > https://review.opendev.org/#/c/681835/1
> 
>          >
> 
>          > https://review.opendev.org/#/c/681842/1
> 
>          >
> 
>          > https://review.opendev.org/#/c/681847/1
> 
>          >
> 
>          > https://review.opendev.org/#/c/681848/1
> 
>          >
> 
>          > https://review.opendev.org/#/c/681851/1
> 
>          >
> 
>          > https://review.opendev.org/#/c/681852/1
> 
>          >
> 
>          > https://review.opendev.org/#/c/681854/1
> 
>          >
> 
>          > https://review.opendev.org/#/c/681856/1
> 
>          >
> 
>          > https://review.opendev.org/#/c/681890/1
> 
>          >
> 
>          > https://review.opendev.org/#/c/681892/1
> 
>          >
> 
>          > https://review.opendev.org/#/c/681892/1
> 
>          >
> 
>          > https://review.opendev.org/#/c/681898/1
> 
>          >
> 
>          > https://review.opendev.org/#/c/681900/1
> 
>          >
> 
>          > https://review.opendev.org/#/c/681901/1
> 
>          >
> 
>          > https://review.opendev.org/#/c/681902/1
> 
>          >
> 
>          >
> 
>          >
> 
>          >
> 
>          > _______________________________________________
> 
>          > Starlingx-discuss mailing list
> 
>          > Starlingx-discuss at lists.starlingx.io
>         <mailto:Starlingx-discuss at lists.starlingx.io>
> 
>          >
>         http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
> 
> 
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
> 



More information about the Starlingx-discuss mailing list