-
Notifications
You must be signed in to change notification settings - Fork 65
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
Implement cachePath Option for Preflight to Utilize Pre-cached Container Images #1162
Comments
@ansvu Why are images being tested more then once? Preflight only pulls the images it's asked to pull. I'm not sure what you mean by a cache here, since it would be for a single image, which again should only be tested once. |
the process of our current certification is seperated into 2 steps , 1. pre-check image without submit for identifying issues to fix and then 2. formal run certification process that include preflight testing, submit to project and publication. so, during the pre-check phase , there will be multiple run on Preflight, if we can pre-cache the image to local storage, then each time when pulling new image with correction from repo, it only update correction portion/layer without pull whole image again, and in step 2, we still need a final run and submit good report to portal, this will only use last good tested pre-cache image without pulling from repo again, this is our use case. |
I don't think I'd be willing to trust a cache on disk, since someone could manipulate the files in the cache on disk to circumvent the testing/certification. This one of many reasons why we require a remote registry during submission, and not a local registry. |
understand, but my use case is for specific env where the jumphost which run test is located in lab behind the firewall or have authentircation to access cluster and repository(e.g., via vpn) , the security is in place. this is most telco partner cases to run certification tool. or you talking about someone change the cache files to make test pass? regarding to remote registry, it's a common case for many partner to use local registry instead of repo outside of company. we have to adapt this on-premise env for certification test. |
Yes, this is exactly what I am talking about, and like mentioned why we do not trust a local registry. We do not have to adapt this to support on-prem, if it opens things up for further manipulation vectors. |
Is your feature request related to a problem? Please describe
Our goal is to identify bottlenecks in the CNF certification process for partners.
Specifically, we're looking at container image certification, where the preflight scanning tool becomes a significant time factor for larger images (over 94 images) and can take up to 5 hours.
One key issue we found is that preflight currently doesn't leverage local image caching.
This means it rescans the same images repeatedly and pull them every scan, contributing to the overall processing time.
crane.Pull: https://github.com/redhat-openshift-ecosystem/openshift-preflight/blob/main/internal/engine/engine.go#L125-L126
Interestingly, we observed that the preflight tool creates a temporary cache directory in /tmp/ during the scan. However, this cache is removed after the scan completes.
Created cache: https://github.com/redhat-openshift-ecosystem/openshift-preflight/blob/main/internal/engine/engine.go#L143-L148
Removed tmpdir(cache): https://github.com/redhat-openshift-ecosystem/openshift-preflight/blob/main/internal/engine/engine.go#L138
Describe the solution you'd like.
Implementing an option to use pre-cached images through a cachePath parameter would be a valuable improvement. This would eliminate the need to repeatedly pull container images on every scan, significantly reducing processing time.
Describe alternatives you've considered.
Based on our test result using crane manually, implementing a cachePath option appears to be the most effective approach for preflight scan time optimization.
Additional context.
Testing crane manually to pull image with cache-path option
Before cache saved:
Total: 115s
Using pre-cached:
total: 13s
As you can see it saved almost 2mins.
We understand that
Pre-caching images
improves scan times but it requires additional local storage.The text was updated successfully, but these errors were encountered: