-
Notifications
You must be signed in to change notification settings - Fork 248
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
Bugfixes for image compatibility feature #2010
Bugfixes for image compatibility feature #2010
Conversation
Signed-off-by: Marcin Franczyk <[email protected]>
Signed-off-by: Marcin Franczyk <[email protected]>
Signed-off-by: Marcin Franczyk <[email protected]>
Hi @mfranczy. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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-sigs/prow repository. |
✅ Deploy Preview for kubernetes-sigs-nfd ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
@mfranczy: GitHub didn't allow me to request PR reviews from the following users: ChaoyiHuang. Note that only kubernetes-sigs members and repo collaborators can review this PR, and authors cannot review their own PRs. 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-sigs/prow repository. |
/cherry-pick release-0.17 |
@marquiz: once the present PR merges, I will cherry-pick it on top of 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-sigs/prow repository. |
/ok-to-test |
/test pull-node-feature-discovery-build-image-cross-generic |
@@ -97,6 +97,7 @@ func (nv *nodeValidator) Execute(ctx context.Context) ([]*CompatibilityStatus, e | |||
} | |||
|
|||
func evaluateRuleStatus(rule *nfdv1alpha1.Rule, matchStatus *nodefeaturerule.MatchStatus) ProcessedRuleStatus { |
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 this function be a function of (nv *nodeValidator). and the function refactory will enhance the readbility
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 could add the refactoring stuff as TODO notes and/or create a GitHub issue for tracking and concentrate solely on bugfixes in this PR. WDYT?
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.
I agree. I plan to do refactoring but in a different PR, in this specific one I would prefer only to concentrate on the bugfixes I provided.
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.
TODO notes sounds good
@@ -97,6 +97,7 @@ func (nv *nodeValidator) Execute(ctx context.Context) ([]*CompatibilityStatus, e | |||
} | |||
|
|||
func evaluateRuleStatus(rule *nfdv1alpha1.Rule, matchStatus *nodefeaturerule.MatchStatus) ProcessedRuleStatus { | |||
var matchedFeatureTerms nfdv1alpha1.FeatureMatcher | |||
out := ProcessedRuleStatus{Name: rule.Name, IsMatch: matchStatus.IsMatch} | |||
|
|||
evaluateFeatureMatcher := func(featureMatcher, matchedFeatureTerms nfdv1alpha1.FeatureMatcher) []MatchedExpression { |
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.
nested evaluateFeatureMatcher function make it become a little long for evaluateRuleStatus. could the evaluateFeatureMatcher become a function of (nv *nodeValidator)
and in the evaluateFeatureMatcher nested function, processedTerm := range matchedFeatureTerms where matchedFeatureTerms comes from the function parameter in expression condition, and processedTerm := range matchStatus.MatchedFeaturesTerms where the processedTerm comes from the parent function parameter.
the evaluateFeatureMatcher will process two condition, it can be divided into two function, which handle expression or name separately, or one function with same parameters, but processing according to evaluation on expression or name.
obviously that the processedTerm have multiple sources, so we can handle it two function layer:
one is to handle various sources, the other layer to handle proecssedTerm
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.
@ChaoyiHuang I will provide the refactored code but in a different PR. I would prefer that it doesn't grow too much that we can merge the fixes fast.
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.
Also, doing refactoring in a separate PR makes backporting to release branch cleaner and less risky
EDIT: meaning if possible we only backport the bugfixes but not the refactoring
@@ -163,11 +164,17 @@ func evaluateRuleStatus(rule *nfdv1alpha1.Rule, matchStatus *nodefeaturerule.Mat | |||
} | |||
|
|||
if matchFeatures := rule.MatchFeatures; matchFeatures != nil { | |||
out.MatchedExpressions = evaluateFeatureMatcher(matchFeatures, matchStatus.MatchedFeaturesTerms) | |||
if matchStatus.MatchFeatureStatus != nil { |
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.
non supported features in nfd could be added as some test cases. the tool should deal with unrecognized feature name or expression as well. in the future may check whether non-supported features are in image-compatibility artifact
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.
I have added a unit test to check the behaviour. Currently, it's allowed to add any feature to the spec, if it doesn't exist the rule will fail. The user will get a log about it (in debug mode). In the future, we can think of additional behaviours (like stopping the execution if the feature doesn't exist etc.).
Signed-off-by: Marcin Franczyk <[email protected]>
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 to go from my pov.
@ChaoyiHuang WDYT?
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: marquiz, mfranczy 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 |
/lgtm |
LGTM label has been added. Git tree hash: 1bca56f2209f55853fae1b45f9d8dff338bc0019
|
@marquiz: new pull request created: #2016 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-sigs/prow repository. |
Bugfixes: