*: add support for pinned_images in crio configuration #6862
Conversation
eee2f50 to
3ddab6a
Compare
3b65e7d to
91d11ef
Compare
2921be0 to
f8bfaa6
Compare
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #6862 +/- ##
==========================================
+ Coverage 49.64% 49.75% +0.11%
==========================================
Files 127 127
Lines 15040 15090 +50
==========================================
+ Hits 7466 7508 +42
- Misses 6686 6693 +7
- Partials 888 889 +1 |
f8bfaa6 to
b8ec87d
Compare
5812428 to
b914864
Compare
|
couple more nits, and it would be really cool to unit test CompileRegexpsForPinnedImages to have some examples of what we expect to work, otherwise LGTM |
fda22ec to
3c7079d
Compare
|
/approve LGTM, nicely done @cri-o/cri-o-maintainers PTAL |
|
/test e2e-gcp-ovn |
| regexps := make([]*regexp.Regexp, 0, len(patterns)) | ||
| for _, pattern := range patterns { | ||
| var re *regexp.Regexp | ||
| switch { |
There was a problem hiding this comment.
Hm, I’ll not block on this but I’d prefer having plain globs or regular expressions without any further checks.
3c7079d to
a9d8648
Compare
|
/test ci-fedora-integration |
|
/test e2e-gcp-ovn |
|
/retest |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: haircommander, saschagrunert, sohankunkerkar The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Fixes: cri-o#6835 Signed-off-by: Sohan Kunkerkar <[email protected]>
Signed-off-by: Sohan Kunkerkar <[email protected]>
a9d8648 to
f9abf50
Compare
|
fixed the validate-docs warning: https://github.com/cri-o/cri-o/actions/runs/4895446554/jobs/8741105904?pr=6862 |
|
/retest |
|
/lgtm |
| } | ||
| } | ||
|
|
||
| name, _, _ := sortNamesByType(image.Names) |
There was a problem hiding this comment.
How is this supposed to work with images that have multiple names?
There was a problem hiding this comment.
Are you asking how sortNamesByType will behave with multiple names?
There was a problem hiding this comment.
I did read that code. I don’t see that the current implementation provides a predictable behavior for users (the order of image.Names, in the current implementation, seems to depend on the order in which image names were pulled, and that’s not at all promised by the API).
My first guess is that all names in image.Names should be processed by the filter, but I didn’t look into the use cases of pinned images.
There was a problem hiding this comment.
My first guess is that all names in image.Names should be processed by the filter, but I didn’t look into the use cases of pinned images.
the idea is to disqualify an image for kubelet garbage collection. Since the order of the names isn't guaranteed, it does sound like each should be considered to see if the image should be disqualified
Fixes: #6835
What type of PR is this?
/kind feature
What this PR does / why we need it:
Which issue(s) this PR fixes:
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Yes