-
Notifications
You must be signed in to change notification settings - Fork 286
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
perf(tools): fabric 1.x AIO image pre-fetching #649
Labels
dependencies
Pull requests that update a dependency file
Developer_Experience
enhancement
New feature or request
Fabric
good-first-issue
Good for newcomers
Hacktoberfest
Hacktoberfest participants are welcome to take a stab at issues marked with this label.
Nice-to-Have
Performance
Everything related to how fast/efficient the software or it's tooling (e.g. build) is.
Comments
petermetz
added
dependencies
Pull requests that update a dependency file
Developer_Experience
enhancement
New feature or request
Fabric
good-first-issue
Good for newcomers
Hacktoberfest
Hacktoberfest participants are welcome to take a stab at issues marked with this label.
Nice-to-Have
Performance
Everything related to how fast/efficient the software or it's tooling (e.g. build) is.
labels
Mar 10, 2021
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Apr 14, 2021
Fixes hyperledger-cacti#649 In addition to that fix it also fixes a pre-fetching bug in the 2.x image which was stopping it from actually using the pre-fetched images on the file-system => the directory paths had to be specified one by one for each image that we pre-fetched, it did not work if you specified a common parent directory where the images were stored, so this commit provides a fix for both 1.4.x and 2.x in the sense that they both should no longer hit DockerHub for image downloads at container startup time, only build-time as long as the FABRIC_VERSION env vars were not altered by the person launching the containers (if they were then those different versions will still have to be fetched at runtime). The biggest net positive effect(s) of this commit: 1. Image boot will be much faster, especially on machines where the network is slow. 2. The risk of getting slapped with DockerHub image pull rate limiting goes down significantly. Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Apr 14, 2021
Fixes hyperledger-cacti#649 In addition to that fix it also fixes a pre-fetching bug in the 2.x image which was stopping it from actually using the pre-fetched images on the file-system => the directory paths had to be specified one by one for each image that we pre-fetched, it did not work if you specified a common parent directory where the images were stored, so this commit provides a fix for both 1.4.x and 2.x in the sense that they both should no longer hit DockerHub for image downloads at container startup time, only build-time as long as the FABRIC_VERSION env vars were not altered by the person launching the containers (if they were then those different versions will still have to be fetched at runtime). The biggest net positive effect(s) of this commit: 1. Image boot will be much faster, especially on machines where the network is slow. 2. The risk of getting slapped with DockerHub image pull rate limiting goes down significantly. Also fixes a health check bug where the FABRIC_VERSION build arg was not being exposed as an ENV var in the container and the parsing of the version was failing due to this. Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Apr 20, 2021
Fixes hyperledger-cacti#649 In addition to that fix it also fixes a pre-fetching bug in the 2.x image which was stopping it from actually using the pre-fetched images on the file-system => the directory paths had to be specified one by one for each image that we pre-fetched, it did not work if you specified a common parent directory where the images were stored, so this commit provides a fix for both 1.4.x and 2.x in the sense that they both should no longer hit DockerHub for image downloads at container startup time, only build-time as long as the FABRIC_VERSION env vars were not altered by the person launching the containers (if they were then those different versions will still have to be fetched at runtime). The biggest net positive effect(s) of this commit: 1. Image boot will be much faster, especially on machines where the network is slow. 2. The risk of getting slapped with DockerHub image pull rate limiting goes down significantly. Also fixes a health check bug where the FABRIC_VERSION build arg was not being exposed as an ENV var in the container and the parsing of the version was failing due to this. Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Apr 20, 2021
Fixes hyperledger-cacti#649 In addition to that fix it also fixes a pre-fetching bug in the 2.x image which was stopping it from actually using the pre-fetched images on the file-system => the directory paths had to be specified one by one for each image that we pre-fetched, it did not work if you specified a common parent directory where the images were stored, so this commit provides a fix for both 1.4.x and 2.x in the sense that they both should no longer hit DockerHub for image downloads at container startup time, only build-time as long as the FABRIC_VERSION env vars were not altered by the person launching the containers (if they were then those different versions will still have to be fetched at runtime). The biggest net positive effect(s) of this commit: 1. Image boot will be much faster, especially on machines where the network is slow. 2. The risk of getting slapped with DockerHub image pull rate limiting goes down significantly. Also fixes a health check bug where the FABRIC_VERSION build arg was not being exposed as an ENV var in the container and the parsing of the version was failing due to this. Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
that referenced
this issue
Apr 21, 2021
Fixes #649 In addition to that fix it also fixes a pre-fetching bug in the 2.x image which was stopping it from actually using the pre-fetched images on the file-system => the directory paths had to be specified one by one for each image that we pre-fetched, it did not work if you specified a common parent directory where the images were stored, so this commit provides a fix for both 1.4.x and 2.x in the sense that they both should no longer hit DockerHub for image downloads at container startup time, only build-time as long as the FABRIC_VERSION env vars were not altered by the person launching the containers (if they were then those different versions will still have to be fetched at runtime). The biggest net positive effect(s) of this commit: 1. Image boot will be much faster, especially on machines where the network is slow. 2. The risk of getting slapped with DockerHub image pull rate limiting goes down significantly. Also fixes a health check bug where the FABRIC_VERSION build arg was not being exposed as an ENV var in the container and the parsing of the version was failing due to this. Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
dependencies
Pull requests that update a dependency file
Developer_Experience
enhancement
New feature or request
Fabric
good-first-issue
Good for newcomers
Hacktoberfest
Hacktoberfest participants are welcome to take a stab at issues marked with this label.
Nice-to-Have
Performance
Everything related to how fast/efficient the software or it's tooling (e.g. build) is.
Description
Make the 1.x Fabric AIO image pre-fetch the docker images for Fabric at (AIO) image build time the same way the 2.x already does it here:
tools/docker/fabric-all-in-one/Dockerfile_v2.x
And in the network runner script of the container:
tar -cC '/etc/hyperledger/fabric/' . | docker load
(add more description and relevant links)
Acceptance Criteria
cc: @takeutak @sfuji822 @hartm @jonathan-m-hamilton @AzaharaC @jordigiam @kikoncuo
The text was updated successfully, but these errors were encountered: