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
k8s-ci-robot
added
cncf-cla: yes
k8s-ci-robot
added
the
approved
|
Still thinking about some special cases of this... |
k8s-ci-robot
added
the
do-not-merge/hold
marquiz
force-pushed
the
devel/empty-matchexpression
branch
from
0eaa28a
to
b0b4911
Compare
k8s-ci-robot
added
size/L
|
Updated, now I think it is better |
k8s-ci-robot
removed
the
do-not-merge/hold
k8s-ci-robot
changed the title
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.
marquiz
force-pushed
the
devel/empty-matchexpression
branch
from
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 |
k8s-ci-robot
added
the
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.