[Starlingx-discuss] [Build] Build Avoidance
Build Avoidance, a build tool improvement.* * *Purpose:* Greatly reduce build times after a repo sync for designers working within a regional office. For a new workspace, build-pkgs typically requires 3+ hours, build avoidance typically reduces this step to ~20min. *Limitations:* Little or no benefit for designers who refresh a pre-existing workspace at least daily. (download_mirror.sh, repo sync, generate-cgcs-centos-repo.sh, build-pkgs, build-iso). Not likely to be useful to solo designers, or teleworkers that wish to compile on there home computers. WAN speeds are generally to slow. *Method (in brief):* 1) Reference builds - A server performs a regular (daily?), automated builds using existing methods. Call these the reference builds. - The builds are timestamped, and preserved for some time. (weeks?) - A build CONTEXT is captured, consisting of the SHA of each and every git that contributed to the build. - For each package built, a file shall capture he md5sums of all the source code inputs to the build of that package. - All these build products are accessible locally (e.g. a regional office) via rsync (other protocols can be added later) 2) Designers - build-pkgs --build-avoidance ... will request a build avoidance build. - Additional arguments, and/or environment variables, and/or a config file unique to the regional office, are used to specify a URL to the reference builds. - build-pkgs will: = From newest to oldest, scan the CONTEXTs of the various reference builds. Select the first (most recent) context which satisfies: For every git, the SHA specified in the CONTEXT is present. = The selected context might be slightly out of date, but not by more than a day (assuming daily reference builds). = If the context has not been previously downloaded, then download it now. Meaning download select portions of the reference build workspace into the designer's workspace. This includes all the SRPMS, RPMS, MD5SUMS, and misc supporting files. (~10 min over office LAN) = The designer may have additional commits not present in the reference build, or uncommitted changes. Affected packages will identified by the differing md5sum's, and the package is re-built. (5+ min, depending on what packages have changed) *Requirement:* - The regional office implements an automated build that pulls the latest StarlingX software and builds it on a regular basis. e.g. a daily. Perhaps implemented by Jenkins, cron, or similar tools. - Each build is saved to a unique directory, and preserved for a time that is reflective of how long a designer might be expected to work on a private branch without syncronizing with the master branch. e.g. 2 weeks. - The MY_WORKSPACE directory for the build shall have a common root directory, and a leaf directory that is a time stamp of format YYYY-MM-DD_hh-mm-ss. e.g. MY_WORKSPACE=/localdisk/loadbuild/jenkins/StarlingX/2018-07-19_11-30-21 - Designers can access all build products over the internal network of the regional office. The current prototype employs rsync. Other protocols that can efficiently share/copy/transfer large directories of content can be added as needed.
Thanks Scott!
Build Avoidance, a build tool improvement.
Greatly reduce build times after a repo sync for designers working within a regional office. For a new workspace, build-pkgs typically requires 3+ hours, build avoidance typically reduces this step to ~20min.
Method (in brief):
1) Reference builds
Regional Office could be the results of 2 components: - Reference Mirror - As designer, I do not want to download packages but compile - This is already enabled [0] by Jason and team - It is being implemented at our office in Mexico, we will send our findings - Reference Build - Described here
2) Designers - build-pkgs --build-avoidance ... will request a build avoidance build. - Additional arguments, and/or environment variables, and/or a config file unique to the regional office, are used to specify a URL to the reference builds.
Do we need changes at the Build System level? We will run a proof of concept here just let us know how to get started.
- build-pkgs will: = From newest to oldest, scan the CONTEXTs of the various reference builds. Select the first (most recent) context which satisfies: For every git, the SHA specified in the CONTEXT is present. = The selected context might be slightly out of date, but not by more than a day (assuming daily reference builds). = If the context has not been previously downloaded, then download it now. Meaning download select portions of the reference build workspace into the designer's workspace. This includes all the SRPMS, RPMS, MD5SUMS, and misc supporting files. (~10 min over office LAN)
Can it take a look at our Reference Mirror? [0] https://review.openstack.org/590781
Yes, Build tool changes are required. 1) We must now trigger rebuilds based on changed checksum, rather than time stamps. The timestamps are not reliable when copying files between different build environments. 2) build-pkgs must capture the git context of the build 3) 'build-pkgs --avoidance' is requested. It must now compare the state of your git tree vs the available reference builds, and download the correct one if available. I have these changes under test now. I will be posting reviews in the next few days. Scott On 18-08-29 07:03 PM, Arce Moreno, Abraham wrote:
Thanks Scott!
Build Avoidance, a build tool improvement.
Greatly reduce build times after a repo sync for designers working within a regional office. For a new workspace, build-pkgs typically requires 3+ hours, build avoidance typically reduces this step to ~20min.
Method (in brief):
1) Reference builds Regional Office could be the results of 2 components:
- Reference Mirror - As designer, I do not want to download packages but compile - This is already enabled [0] by Jason and team - It is being implemented at our office in Mexico, we will send our findings - Reference Build - Described here
2) Designers - build-pkgs --build-avoidance ... will request a build avoidance build. - Additional arguments, and/or environment variables, and/or a config file unique to the regional office, are used to specify a URL to the reference builds. Do we need changes at the Build System level? We will run a proof of concept here just let us know how to get started.
- build-pkgs will: = From newest to oldest, scan the CONTEXTs of the various reference builds. Select the first (most recent) context which satisfies: For every git, the SHA specified in the CONTEXT is present. = The selected context might be slightly out of date, but not by more than a day (assuming daily reference builds). = If the context has not been previously downloaded, then download it now. Meaning download select portions of the reference build workspace into the designer's workspace. This includes all the SRPMS, RPMS, MD5SUMS, and misc supporting files. (~10 min over office LAN)
Can it take a look at our Reference Mirror?
So is there anything that you need us to test? Are you modifying the scripts? Can you point us to these changes? I want to make sure we are tracking these changes in storyboard, shall I go ahead and create those stories? Regards Cesar Lara -----Original Message----- From: Scott Little [mailto:scott.little@windriver.com] Sent: Thursday, August 30, 2018 11:37 AM To: Arce Moreno, Abraham <abraham.arce.moreno@intel.com>; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Build] Build Avoidance Yes, Build tool changes are required. 1) We must now trigger rebuilds based on changed checksum, rather than time stamps. The timestamps are not reliable when copying files between different build environments. 2) build-pkgs must capture the git context of the build 3) 'build-pkgs --avoidance' is requested. It must now compare the state of your git tree vs the available reference builds, and download the correct one if available. I have these changes under test now. I will be posting reviews in the next few days. Scott On 18-08-29 07:03 PM, Arce Moreno, Abraham wrote:
Thanks Scott!
Build Avoidance, a build tool improvement.
Greatly reduce build times after a repo sync for designers working within a regional office. For a new workspace, build-pkgs typically requires 3+ hours, build avoidance typically reduces this step to ~20min.
Method (in brief):
1) Reference builds Regional Office could be the results of 2 components:
- Reference Mirror - As designer, I do not want to download packages but compile - This is already enabled [0] by Jason and team - It is being implemented at our office in Mexico, we will send our findings - Reference Build - Described here
2) Designers - build-pkgs --build-avoidance ... will request a build avoidance build. - Additional arguments, and/or environment variables, and/or a config file unique to the regional office, are used to specify a URL to the reference builds. Do we need changes at the Build System level? We will run a proof of concept here just let us know how to get started.
- build-pkgs will: = From newest to oldest, scan the CONTEXTs of the various reference builds. Select the first (most recent) context which satisfies: For every git, the SHA specified in the CONTEXT is present. = The selected context might be slightly out of date, but not by more than a day (assuming daily reference builds). = If the context has not been previously downloaded, then download it now. Meaning download select portions of the reference build workspace into the designer's workspace. This includes all the SRPMS, RPMS, MD5SUMS, and misc supporting files. (~10 min over office LAN)
Can it take a look at our Reference Mirror?
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
There is a story for this already: https://storyboard.openstack.org/#!/story/2002835 I've added Scott's proposal as a comment in the story. -----Original Message----- From: Lara, Cesar [mailto:cesar.lara@intel.com] Sent: Thursday, August 30, 2018 3:34 PM To: Little, Scott; Arce Moreno, Abraham; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Build] Build Avoidance So is there anything that you need us to test? Are you modifying the scripts? Can you point us to these changes? I want to make sure we are tracking these changes in storyboard, shall I go ahead and create those stories? Regards Cesar Lara -----Original Message----- From: Scott Little [mailto:scott.little@windriver.com] Sent: Thursday, August 30, 2018 11:37 AM To: Arce Moreno, Abraham <abraham.arce.moreno@intel.com>; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] [Build] Build Avoidance Yes, Build tool changes are required. 1) We must now trigger rebuilds based on changed checksum, rather than time stamps. The timestamps are not reliable when copying files between different build environments. 2) build-pkgs must capture the git context of the build 3) 'build-pkgs --avoidance' is requested. It must now compare the state of your git tree vs the available reference builds, and download the correct one if available. I have these changes under test now. I will be posting reviews in the next few days. Scott On 18-08-29 07:03 PM, Arce Moreno, Abraham wrote:
Thanks Scott!
Build Avoidance, a build tool improvement.
Greatly reduce build times after a repo sync for designers working within a regional office. For a new workspace, build-pkgs typically requires 3+ hours, build avoidance typically reduces this step to ~20min.
Method (in brief):
1) Reference builds Regional Office could be the results of 2 components:
- Reference Mirror - As designer, I do not want to download packages but compile - This is already enabled [0] by Jason and team - It is being implemented at our office in Mexico, we will send our findings - Reference Build - Described here
2) Designers - build-pkgs --build-avoidance ... will request a build avoidance build. - Additional arguments, and/or environment variables, and/or a config file unique to the regional office, are used to specify a URL to the reference builds. Do we need changes at the Build System level? We will run a proof of concept here just let us know how to get started.
- build-pkgs will: = From newest to oldest, scan the CONTEXTs of the various reference builds. Select the first (most recent) context which satisfies: For every git, the SHA specified in the CONTEXT is present. = The selected context might be slightly out of date, but not by more than a day (assuming daily reference builds). = If the context has not been previously downloaded, then download it now. Meaning download select portions of the reference build workspace into the designer's workspace. This includes all the SRPMS, RPMS, MD5SUMS, and misc supporting files. (~10 min over office LAN)
Can it take a look at our Reference Mirror?
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
I've posted the Build Avoidance wiki https://wiki.openstack.org/wiki/StarlingX/Developer_Guide#Build_Avoidance Reviews welcome. We can relocate it if there is a better home folks can suggest. Scott On 18-08-27 04:17 PM, Scott Little wrote:
Build Avoidance, a build tool improvement.* *
*Purpose:*
Greatly reduce build times after a repo sync for designers working within a regional office. For a new workspace, build-pkgs typically requires 3+ hours, build avoidance typically reduces this step to ~20min.
*Limitations:*
Little or no benefit for designers who refresh a pre-existing workspace at least daily. (download_mirror.sh, repo sync, generate-cgcs-centos-repo.sh, build-pkgs, build-iso).
Not likely to be useful to solo designers, or teleworkers that wish to compile on there home computers. WAN speeds are generally to slow.
*Method (in brief):*
1) Reference builds
- A server performs a regular (daily?), automated builds using existing methods. Call these the reference builds. - The builds are timestamped, and preserved for some time. (weeks?) - A build CONTEXT is captured, consisting of the SHA of each and every git that contributed to the build. - For each package built, a file shall capture he md5sums of all the source code inputs to the build of that package. - All these build products are accessible locally (e.g. a regional office) via rsync (other protocols can be added later)
2) Designers - build-pkgs --build-avoidance ... will request a build avoidance build. - Additional arguments, and/or environment variables, and/or a config file unique to the regional office, are used to specify a URL to the reference builds. - build-pkgs will: = From newest to oldest, scan the CONTEXTs of the various reference builds. Select the first (most recent) context which satisfies: For every git, the SHA specified in the CONTEXT is present. = The selected context might be slightly out of date, but not by more than a day (assuming daily reference builds). = If the context has not been previously downloaded, then download it now. Meaning download select portions of the reference build workspace into the designer's workspace. This includes all the SRPMS, RPMS, MD5SUMS, and misc supporting files. (~10 min over office LAN) = The designer may have additional commits not present in the reference build, or uncommitted changes. Affected packages will identified by the differing md5sum's, and the package is re-built. (5+ min, depending on what packages have changed)
*Requirement:*
- The regional office implements an automated build that pulls the latest StarlingX software and builds it on a regular basis. e.g. a daily. Perhaps implemented by Jenkins, cron, or similar tools. - Each build is saved to a unique directory, and preserved for a time that is reflective of how long a designer might be expected to work on a private branch without syncronizing with the master branch. e.g. 2 weeks. - The MY_WORKSPACE directory for the build shall have a common root directory, and a leaf directory that is a time stamp of format YYYY-MM-DD_hh-mm-ss. e.g. MY_WORKSPACE=/localdisk/loadbuild/jenkins/StarlingX/2018-07-19_11-30-21 - Designers can access all build products over the internal network of the regional office. The current prototype employs rsync. Other protocols that can efficiently share/copy/transfer large directories of content can be added as needed.
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
participants (4)
-
Arce Moreno, Abraham
-
Khalil, Ghada
-
Lara, Cesar
-
Scott Little