-
Notifications
You must be signed in to change notification settings - Fork 77
Update multi-arch validator to check node affinity for multi-platform environments #276
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
Update multi-arch validator to check node affinity for multi-platform environments #276
Conversation
2653a75
to
ada51af
Compare
/assign awgreene |
/unhold |
ada51af
to
0345a47
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Don't have much to say - everything is clear and tests are extensive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, but I'd like to confirm that warnings do not prevent an operator from being published. Thanks for the contribution.
var os = make([]string, 0) | ||
|
||
for _, e := range t.MatchExpressions { | ||
if e.Operator != "In" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This won't support anti-affinity, which I think is fine given the goal of this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The multiarch validator is used in the operator-framework/audit tool to produce a report on the health of operators and is also available for self-validation for operator-sdk authors. It will not block operator publishing. :)
pkg/validation/internal/multiarch.go
Outdated
@@ -297,12 +375,12 @@ func (data *multiArchValidator) inspectImages(images map[string][]platform) map[ | |||
if err != nil { | |||
data.warns = append(data.warns, fmt.Errorf("unable to inspect the image (%s) : %s", k, err)) | |||
|
|||
// We set the Arch and SO as error for we are able to deal witth these cases further | |||
// We set the Arch and OS as error for we are able to deal witth these cases further |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// We set the Arch and OS as error for we are able to deal witth these cases further | |
// We set the Arch and OS as error for we are able to deal with these cases further |
pkg/validation/internal/multiarch.go
Outdated
// checkMissingSupportForOtherImages checks if any image is missing some arch or so found | ||
// (probably the image should support the arch or SO ) | ||
func (data *multiArchValidator) checkMissingSupportForOtherImages() { | ||
for image, plaformFromImage := range data.allOtherImages { | ||
// (probably the image should support the arch or OS ) | ||
func (data *multiArchValidator) checkMissingSupportForOtherImages(images map[string][]platform) { | ||
for image, platformFromImage := range images { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: No functional changes were made in this function other than the new argument.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes - the function is now called twice (once for the non-manager containers, and then again for the relatedImage containers).
So it seemed simpler to me to parameterize the image list.
// Ignore the case when the Platform.Architecture == "error" since that means | ||
// that was not possible to inspect the image | ||
if imageData.Architecture == "error" { | ||
imagePlatformDataValid = false | ||
break | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you explain why it is okay not to log an error here? Is it logged elsewhere when the image fails to be inspected?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is - specifically it is logged at inspection time in line 382.
https://github.com/operator-framework/api/pull/276/files#diff-20ba073b3d34ec5ee84564e23371a9a0653ca0528bd97fe76837efa1289d8c88R382
Some notes on this PR since I've been evaluating it via the operator-sdk instructions as well as trying to run it through the operator-framework/audit tool: The audit report is going to flag all operators as those with warnings since by default, the operator scaffolding does not provide a kube-rbac-proxy node affinity specification. I think this may need to be updated as part of operator-framework/operator-sdk#5983 (or another PR focused on providing more opinionated scaffolding). While this report is technically accurate, it does muddy the signal for the 40 or so operators in the redhat-operator-index that have otherwise been compliant as per Camila's original report. I don't think we should remove it or skip that image, but I do think that it would be good to add nodeAffinity for this image to the scaffolding so future operators don't hit this. |
d64584e
to
228bde0
Compare
228bde0
to
d1bfcb6
Compare
/retest |
@jaypoulz: Cannot trigger testing until a trusted user reviews the PR and leaves an In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: awgreene, jaypoulz The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/lgtm |
Adding a validator to image references for nodeAffinity specifications.
Will check for the following for the CSV images:
In doing so I've built upon the work done by @camilamacedo86.