mirrors/node-feature-discovery
mirrors/node-feature-discovery
1
0
Fork 0
mirror of https://github.com/kubernetes-sigs/node-feature-discovery.git synced 2025-03-09 10:17:04 +00:00
Code Activity
node-feature-discovery/test/e2e/data/nodefeaturerule-1.yaml

119 lines
3.1 KiB
YAML
Raw Normal View History

test/e2e: add tests for NodeFeatureRules Add tests covering the basic functionality of NodeFeatureRule objects, covering different feature types ("flag features", "attribute features" and "instance features") as well as backreferencing (using the output of previously run rules) and templating. The test relies on the "fake" feature source and its default configuration.
2022-07-07 10:40:19 +03:00
apiVersion: nfd.k8s-sigs.io/v1alpha1
kind: NodeFeatureRule
metadata:
name: e2e-test-1
spec:
rules:
#
# Simple test rules for flag features
#
- name: "e2e-flag-test-1"
labels:
e2e-flag-test-1: "true"
vars:
e2e-flag-test-1.not: "false"
matchFeatures:
- feature: "fake.flag"
matchExpressions:
"flag_1": {op: Exists}
apis/nfd: add matchName field in feature matcher terms Extend the format of feature matcher terms (the elements of the arrayspecified under under matchFeatures field) with new matchName field. The value of this field is an expression that is evaluated against the names of feature elements instead of their values (values are matched with the matchExpressions field, instead). The matchName field is useful e.g. in template rules for creating per-feature-element labels based on feature names (instead of values) and in non-template rules for checking if (at least) one of certain feature element names are present. If both matchExpressions and matchName for certain feature matcher term is specified, they both must match in order to get an overall match. Also, in this case the list of matched features (used in templating) is the union of the results from matchExpressions and matchName. An example of creating an "avx512" label if any AVX512* CPUID feature is present: - name: "avx wildcard rule" labels: avx512: "true" matchFeatures: - feature: cpu.cpuid matchName: {op: InRegexp, value: ["^AVX512"]} An example of a template rule creating a dynamic set of labels based on the existence of certain kconfig options. - name: "kconfig template rule" labelsTemplate: | {{ range .kernel.config }}kconfig-{{ .Name }}={{ .Value }} {{ end }} matchFeatures: - feature: kernel.config matchName: {op: In, value: ["SWAP", "X86", "ARM"]} NOTE: this patch changes the corner case of nil/null match expressions with instance features (i.e. "matchExpressions: null"). Previously, we returned all instances for templating but now a nil match expression is not evaluated and no instances for templating are returned.
2022-03-17 18:30:32 +02:00
- name: "e2e-flag-test-2"
labels:
e2e-flag-test-2: "true"
matchFeatures:
- feature: "fake.flag"
matchName: {op: In, value: ["flag_2"]}
test/e2e: add tests for NodeFeatureRules Add tests covering the basic functionality of NodeFeatureRule objects, covering different feature types ("flag features", "attribute features" and "instance features") as well as backreferencing (using the output of previously run rules) and templating. The test relies on the "fake" feature source and its default configuration.
2022-07-07 10:40:19 +03:00
# Negative test not supposed to create a label
- name: "e2e-flag-test-neg-1"
labels:
e2e-flag-test-neg-1: "true"
matchFeatures:
- feature: "fake.flag"
matchExpressions:
"flag_1": {op: DoesNotExist}
apis/nfd: add matchName field in feature matcher terms Extend the format of feature matcher terms (the elements of the arrayspecified under under matchFeatures field) with new matchName field. The value of this field is an expression that is evaluated against the names of feature elements instead of their values (values are matched with the matchExpressions field, instead). The matchName field is useful e.g. in template rules for creating per-feature-element labels based on feature names (instead of values) and in non-template rules for checking if (at least) one of certain feature element names are present. If both matchExpressions and matchName for certain feature matcher term is specified, they both must match in order to get an overall match. Also, in this case the list of matched features (used in templating) is the union of the results from matchExpressions and matchName. An example of creating an "avx512" label if any AVX512* CPUID feature is present: - name: "avx wildcard rule" labels: avx512: "true" matchFeatures: - feature: cpu.cpuid matchName: {op: InRegexp, value: ["^AVX512"]} An example of a template rule creating a dynamic set of labels based on the existence of certain kconfig options. - name: "kconfig template rule" labelsTemplate: | {{ range .kernel.config }}kconfig-{{ .Name }}={{ .Value }} {{ end }} matchFeatures: - feature: kernel.config matchName: {op: In, value: ["SWAP", "X86", "ARM"]} NOTE: this patch changes the corner case of nil/null match expressions with instance features (i.e. "matchExpressions: null"). Previously, we returned all instances for templating but now a nil match expression is not evaluated and no instances for templating are returned.
2022-03-17 18:30:32 +02:00
- name: "e2e-flag-test-neg-2"
labels:
e2e-flag-test-neg-2: "true"
matchFeatures:
- feature: "fake.flag"
matchName: {op: In, value: ["flag_x"]}
test/e2e: add tests for NodeFeatureRules Add tests covering the basic functionality of NodeFeatureRule objects, covering different feature types ("flag features", "attribute features" and "instance features") as well as backreferencing (using the output of previously run rules) and templating. The test relies on the "fake" feature source and its default configuration.
2022-07-07 10:40:19 +03:00
#
# Simple test rules for attribute features
#
- name: "e2e-attribute-test-1"
labels:
e2e-attribute-test-1: "true"
vars:
e2e-attribute-test-1.not: "false"
matchFeatures:
- feature: "fake.attribute"
matchExpressions:
"attr_1": {op: IsTrue}
"attr_2": {op: IsFalse}
apis/nfd: add matchName field in feature matcher terms Extend the format of feature matcher terms (the elements of the arrayspecified under under matchFeatures field) with new matchName field. The value of this field is an expression that is evaluated against the names of feature elements instead of their values (values are matched with the matchExpressions field, instead). The matchName field is useful e.g. in template rules for creating per-feature-element labels based on feature names (instead of values) and in non-template rules for checking if (at least) one of certain feature element names are present. If both matchExpressions and matchName for certain feature matcher term is specified, they both must match in order to get an overall match. Also, in this case the list of matched features (used in templating) is the union of the results from matchExpressions and matchName. An example of creating an "avx512" label if any AVX512* CPUID feature is present: - name: "avx wildcard rule" labels: avx512: "true" matchFeatures: - feature: cpu.cpuid matchName: {op: InRegexp, value: ["^AVX512"]} An example of a template rule creating a dynamic set of labels based on the existence of certain kconfig options. - name: "kconfig template rule" labelsTemplate: | {{ range .kernel.config }}kconfig-{{ .Name }}={{ .Value }} {{ end }} matchFeatures: - feature: kernel.config matchName: {op: In, value: ["SWAP", "X86", "ARM"]} NOTE: this patch changes the corner case of nil/null match expressions with instance features (i.e. "matchExpressions: null"). Previously, we returned all instances for templating but now a nil match expression is not evaluated and no instances for templating are returned.
2022-03-17 18:30:32 +02:00
- name: "e2e-attribute-test-2"
labels:
e2e-attribute-test-2: "true"
matchFeatures:
- feature: "fake.attribute"
matchName: {op: In, value: ["attr_2", "attr_x"]}
test/e2e: add tests for NodeFeatureRules Add tests covering the basic functionality of NodeFeatureRule objects, covering different feature types ("flag features", "attribute features" and "instance features") as well as backreferencing (using the output of previously run rules) and templating. The test relies on the "fake" feature source and its default configuration.
2022-07-07 10:40:19 +03:00
# Negative test not supposed to create a label
- name: "e2e-attribute-test-neg-1"
labels:
e2e-attribute-test-neg-1: "true"
matchFeatures:
- feature: "fake.attribute"
matchExpressions:
"attr_1": {op: IsTrue}
"attr_2": {op: IsTrue}
apis/nfd: add matchName field in feature matcher terms Extend the format of feature matcher terms (the elements of the arrayspecified under under matchFeatures field) with new matchName field. The value of this field is an expression that is evaluated against the names of feature elements instead of their values (values are matched with the matchExpressions field, instead). The matchName field is useful e.g. in template rules for creating per-feature-element labels based on feature names (instead of values) and in non-template rules for checking if (at least) one of certain feature element names are present. If both matchExpressions and matchName for certain feature matcher term is specified, they both must match in order to get an overall match. Also, in this case the list of matched features (used in templating) is the union of the results from matchExpressions and matchName. An example of creating an "avx512" label if any AVX512* CPUID feature is present: - name: "avx wildcard rule" labels: avx512: "true" matchFeatures: - feature: cpu.cpuid matchName: {op: InRegexp, value: ["^AVX512"]} An example of a template rule creating a dynamic set of labels based on the existence of certain kconfig options. - name: "kconfig template rule" labelsTemplate: | {{ range .kernel.config }}kconfig-{{ .Name }}={{ .Value }} {{ end }} matchFeatures: - feature: kernel.config matchName: {op: In, value: ["SWAP", "X86", "ARM"]} NOTE: this patch changes the corner case of nil/null match expressions with instance features (i.e. "matchExpressions: null"). Previously, we returned all instances for templating but now a nil match expression is not evaluated and no instances for templating are returned.
2022-03-17 18:30:32 +02:00
- name: "e2e-attribute-test-neg-2"
labels:
e2e-attribute-test-neg-2: "true"
matchFeatures:
- feature: "fake.attribute"
matchName: {op: In, value: ["attr_x"]}
test/e2e: add tests for NodeFeatureRules Add tests covering the basic functionality of NodeFeatureRule objects, covering different feature types ("flag features", "attribute features" and "instance features") as well as backreferencing (using the output of previously run rules) and templating. The test relies on the "fake" feature source and its default configuration.
2022-07-07 10:40:19 +03:00
#
apis/nfd: add matchName field in feature matcher terms Extend the format of feature matcher terms (the elements of the arrayspecified under under matchFeatures field) with new matchName field. The value of this field is an expression that is evaluated against the names of feature elements instead of their values (values are matched with the matchExpressions field, instead). The matchName field is useful e.g. in template rules for creating per-feature-element labels based on feature names (instead of values) and in non-template rules for checking if (at least) one of certain feature element names are present. If both matchExpressions and matchName for certain feature matcher term is specified, they both must match in order to get an overall match. Also, in this case the list of matched features (used in templating) is the union of the results from matchExpressions and matchName. An example of creating an "avx512" label if any AVX512* CPUID feature is present: - name: "avx wildcard rule" labels: avx512: "true" matchFeatures: - feature: cpu.cpuid matchName: {op: InRegexp, value: ["^AVX512"]} An example of a template rule creating a dynamic set of labels based on the existence of certain kconfig options. - name: "kconfig template rule" labelsTemplate: | {{ range .kernel.config }}kconfig-{{ .Name }}={{ .Value }} {{ end }} matchFeatures: - feature: kernel.config matchName: {op: In, value: ["SWAP", "X86", "ARM"]} NOTE: this patch changes the corner case of nil/null match expressions with instance features (i.e. "matchExpressions: null"). Previously, we returned all instances for templating but now a nil match expression is not evaluated and no instances for templating are returned.
2022-03-17 18:30:32 +02:00
# Simple test rules for instance features
test/e2e: add tests for NodeFeatureRules Add tests covering the basic functionality of NodeFeatureRule objects, covering different feature types ("flag features", "attribute features" and "instance features") as well as backreferencing (using the output of previously run rules) and templating. The test relies on the "fake" feature source and its default configuration.
2022-07-07 10:40:19 +03:00
#
- name: "e2e-instance-test-1"
labels:
e2e-instance-test-1: "true"
vars:
e2e-instance-test-1.not: "false"
e2e-instance-test-1.123: "123"
matchFeatures:
- feature: "fake.instance"
matchExpressions:
"attr_1": {op: In, value: ["true"]}
"attr_3": {op: Gt, value: ["10"]}
apis/nfd: add matchName field in feature matcher terms Extend the format of feature matcher terms (the elements of the arrayspecified under under matchFeatures field) with new matchName field. The value of this field is an expression that is evaluated against the names of feature elements instead of their values (values are matched with the matchExpressions field, instead). The matchName field is useful e.g. in template rules for creating per-feature-element labels based on feature names (instead of values) and in non-template rules for checking if (at least) one of certain feature element names are present. If both matchExpressions and matchName for certain feature matcher term is specified, they both must match in order to get an overall match. Also, in this case the list of matched features (used in templating) is the union of the results from matchExpressions and matchName. An example of creating an "avx512" label if any AVX512* CPUID feature is present: - name: "avx wildcard rule" labels: avx512: "true" matchFeatures: - feature: cpu.cpuid matchName: {op: InRegexp, value: ["^AVX512"]} An example of a template rule creating a dynamic set of labels based on the existence of certain kconfig options. - name: "kconfig template rule" labelsTemplate: | {{ range .kernel.config }}kconfig-{{ .Name }}={{ .Value }} {{ end }} matchFeatures: - feature: kernel.config matchName: {op: In, value: ["SWAP", "X86", "ARM"]} NOTE: this patch changes the corner case of nil/null match expressions with instance features (i.e. "matchExpressions: null"). Previously, we returned all instances for templating but now a nil match expression is not evaluated and no instances for templating are returned.
2022-03-17 18:30:32 +02:00
- name: "e2e-instance-test-2"
labels:
e2e-instance-test-2: "true"
matchFeatures:
- feature: "fake.instance"
matchName: {op: In, value: ["attr_1", "attr_x"]}
test/e2e: add tests for NodeFeatureRules Add tests covering the basic functionality of NodeFeatureRule objects, covering different feature types ("flag features", "attribute features" and "instance features") as well as backreferencing (using the output of previously run rules) and templating. The test relies on the "fake" feature source and its default configuration.
2022-07-07 10:40:19 +03:00
# Negative test not supposed to create a label
- name: "e2e-instance-test-neg-1"
labels:
e2e-instance-test-neg-1: "true"
matchFeatures:
- feature: "fake.instance"
matchExpressions:
"attr_1": {op: In, value: ["true"]}
"attr_3": {op: Lt, value: ["10"]}
apis/nfd: add matchName field in feature matcher terms Extend the format of feature matcher terms (the elements of the arrayspecified under under matchFeatures field) with new matchName field. The value of this field is an expression that is evaluated against the names of feature elements instead of their values (values are matched with the matchExpressions field, instead). The matchName field is useful e.g. in template rules for creating per-feature-element labels based on feature names (instead of values) and in non-template rules for checking if (at least) one of certain feature element names are present. If both matchExpressions and matchName for certain feature matcher term is specified, they both must match in order to get an overall match. Also, in this case the list of matched features (used in templating) is the union of the results from matchExpressions and matchName. An example of creating an "avx512" label if any AVX512* CPUID feature is present: - name: "avx wildcard rule" labels: avx512: "true" matchFeatures: - feature: cpu.cpuid matchName: {op: InRegexp, value: ["^AVX512"]} An example of a template rule creating a dynamic set of labels based on the existence of certain kconfig options. - name: "kconfig template rule" labelsTemplate: | {{ range .kernel.config }}kconfig-{{ .Name }}={{ .Value }} {{ end }} matchFeatures: - feature: kernel.config matchName: {op: In, value: ["SWAP", "X86", "ARM"]} NOTE: this patch changes the corner case of nil/null match expressions with instance features (i.e. "matchExpressions: null"). Previously, we returned all instances for templating but now a nil match expression is not evaluated and no instances for templating are returned.
2022-03-17 18:30:32 +02:00
- name: "e2e-instance-test-neg-2"
labels:
e2e-instance-test-neg-2: "true"
matchFeatures:
- feature: "fake.instance"
matchName: {op: In, value: ["attr_x"]}
Copy permalink