apis/nfd: empty match expression set returns no features for templates #787
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Still thinking about some special cases of this... |
0eaa28a to
b0b4911
Compare
|
Updated, now I think it is better |
This patch changes a rare corner case of custom label rules with an empty set of matchexpressions. The patch removes a special case where an empty match expression set matched everything and returned all feature elements for templates to consume. With this patch the match expression set logically evaluates all expressions in the set and returns all matches - if there are no expressions there are no matches and no matched features are returned. However, the overall match result (determining if "non-template" labels will be created) in this special case will be "true" as before as none of the zero match expressions failed. The former behavior was somewhat illogical and counterintuitive: having 1 to N expressions matched and returned 1 to N features (at most), but, having 0 expressions always matched everything and returned all features. This was some leftover proof-of-concept functionality (for some possible future extensions) that should have been removed before merging.
b0b4911 to
36341bf
Compare
|
/assign zvonkok ArangoGutierrez |
|
tested ✅ apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: node-feature-discovery
images:
- name: '*'
newName: quay.io/eduardoarango/node-feature-discovery
newTag: v0.11.0-devel-69-g36341bf4
resources:
- deployment/overlays/default |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ArangoGutierrez, marquiz 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 |
|
Up to Zvonko for final lgtm |
|
/lgtm |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch changes a rare corner case of custom label rules with an
empty set of matchexpressions. The patch removes a special case where an
empty match expression set matched everything and returned all feature
elements for templates to consume. With this patch the match expression
set logically evaluates all expressions in the set and returns all
matches - if there are no expressions there are no matches and no
matched features are returned. However, the overall match result
(determining if "non-template" labels will be created) in this special
case will be "true" as before as none of the zero match expressions
failed.
The former behavior was somewhat illogical and counterintuitive: having
1 to N expressions matched and returned 1 to N features (at most), but,
having 0 expressions always matched everything and returned all
features. This was some leftover proof-of-concept functionality (for
some possible future extensions) that should have been removed before
merging.