1
0
Fork 0
mirror of https://github.com/kubernetes-sigs/node-feature-discovery.git synced 2025-03-08 17:57:00 +00:00
node-feature-discovery/pkg/apis/nfd/v1alpha1/rule_test.go

195 lines
6.1 KiB
Go
Raw Normal View History

source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
/*
Copyright 2021 The Kubernetes Authors.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/
package v1alpha1
source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
import (
"testing"
"github.com/stretchr/testify/assert"
"sigs.k8s.io/node-feature-discovery/pkg/api/feature"
)
func TestRule(t *testing.T) {
f := map[string]*feature.DomainFeatures{}
r1 := Rule{Labels: map[string]string{"label-1": "", "label-2": "true"}}
r2 := Rule{
Labels: map[string]string{"label-1": "label-val-1"},
MatchFeatures: FeatureMatcher{
FeatureMatcherTerm{
Feature: "domain-1.kf-1",
MatchExpressions: MatchExpressionSet{
Expressions: Expressions{"key-1": MustCreateMatchExpression(MatchExists)},
},
source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
},
},
}
// Test totally empty features
m, err := r1.Execute(f)
source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
assert.Nilf(t, err, "unexpected error: %v", err)
assert.Equal(t, r1.Labels, m, "empty matcher should have matched empty features")
_, err = r2.Execute(f)
source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
assert.Error(t, err, "matching agains a missing domain should have returned an error")
// Test empty domain
d := feature.NewDomainFeatures()
f["domain-1"] = d
m, err = r1.Execute(f)
source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
assert.Nilf(t, err, "unexpected error: %v", err)
assert.Equal(t, r1.Labels, m, "empty matcher should have matched empty features")
_, err = r2.Execute(f)
source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
assert.Error(t, err, "matching agains a missing feature type should have returned an error")
// Test empty feature sets
d.Keys["kf-1"] = feature.NewKeyFeatures()
d.Values["vf-1"] = feature.NewValueFeatures(nil)
d.Instances["if-1"] = feature.NewInstanceFeatures(nil)
m, err = r1.Execute(f)
source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
assert.Nilf(t, err, "unexpected error: %v", err)
assert.Equal(t, r1.Labels, m, "empty matcher should have matched empty features")
m, err = r2.Execute(f)
source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
assert.Nilf(t, err, "unexpected error: %v", err)
assert.Nil(t, m, "unexpected match")
// Test non-empty feature sets
d.Keys["kf-1"].Elements["key-x"] = feature.Nil{}
d.Values["vf-1"].Elements["key-1"] = "val-x"
d.Instances["if-1"] = feature.NewInstanceFeatures([]feature.InstanceFeature{
*feature.NewInstanceFeature(map[string]string{"attr-1": "val-x"})})
m, err = r1.Execute(f)
source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
assert.Nilf(t, err, "unexpected error: %v", err)
assert.Equal(t, r1.Labels, m, "empty matcher should have matched empty features")
// Match "key" features
m, err = r2.Execute(f)
source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
assert.Nilf(t, err, "unexpected error: %v", err)
assert.Nil(t, m, "keys should not have matched")
d.Keys["kf-1"].Elements["key-1"] = feature.Nil{}
m, err = r2.Execute(f)
source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
assert.Nilf(t, err, "unexpected error: %v", err)
assert.Equal(t, r2.Labels, m, "keys should have matched")
// Match "value" features
r3 := Rule{
Labels: map[string]string{"label-3": "label-val-3", "empty": ""},
MatchFeatures: FeatureMatcher{
FeatureMatcherTerm{
Feature: "domain-1.vf-1",
MatchExpressions: MatchExpressionSet{
Expressions: Expressions{"key-1": MustCreateMatchExpression(MatchIn, "val-1")},
},
source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
},
},
}
m, err = r3.Execute(f)
source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
assert.Nilf(t, err, "unexpected error: %v", err)
assert.Nil(t, m, "values should not have matched")
d.Values["vf-1"].Elements["key-1"] = "val-1"
m, err = r3.Execute(f)
source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
assert.Nilf(t, err, "unexpected error: %v", err)
assert.Equal(t, r3.Labels, m, "values should have matched")
// Match "instance" features
r4 := Rule{
Labels: map[string]string{"label-4": "label-val-4"},
MatchFeatures: FeatureMatcher{
FeatureMatcherTerm{
Feature: "domain-1.if-1",
MatchExpressions: MatchExpressionSet{
Expressions: Expressions{"attr-1": MustCreateMatchExpression(MatchIn, "val-1")},
},
source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
},
},
}
m, err = r4.Execute(f)
source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
assert.Nilf(t, err, "unexpected error: %v", err)
assert.Nil(t, m, "instances should not have matched")
d.Instances["if-1"].Elements[0].Attributes["attr-1"] = "val-1"
m, err = r4.Execute(f)
source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
assert.Nilf(t, err, "unexpected error: %v", err)
assert.Equal(t, r4.Labels, m, "instances should have matched")
// Test multiple feature matchers
r5 := Rule{
Labels: map[string]string{"label-5": "label-val-5"},
MatchFeatures: FeatureMatcher{
FeatureMatcherTerm{
Feature: "domain-1.vf-1",
MatchExpressions: MatchExpressionSet{
Expressions: Expressions{"key-1": MustCreateMatchExpression(MatchIn, "val-x")},
},
source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
},
FeatureMatcherTerm{
Feature: "domain-1.if-1",
MatchExpressions: MatchExpressionSet{
Expressions: Expressions{"attr-1": MustCreateMatchExpression(MatchIn, "val-1")},
},
source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
},
},
}
m, err = r5.Execute(f)
source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
assert.Nilf(t, err, "unexpected error: %v", err)
assert.Nil(t, m, "instances should not have matched")
r5.MatchFeatures[0].MatchExpressions.Expressions["key-1"] = MustCreateMatchExpression(MatchIn, "val-1")
m, err = r5.Execute(f)
source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
assert.Nilf(t, err, "unexpected error: %v", err)
assert.Equal(t, r5.Labels, m, "instances should have matched")
// Test MatchAny
r5.MatchAny = []MatchAnyElem{
MatchAnyElem{
MatchFeatures: FeatureMatcher{
FeatureMatcherTerm{
Feature: "domain-1.kf-1",
MatchExpressions: MatchExpressionSet{
Expressions: Expressions{"key-na": MustCreateMatchExpression(MatchExists)},
},
},
},
},
}
m, err = r5.Execute(f)
assert.Nilf(t, err, "unexpected error: %v", err)
assert.Nil(t, m, "instances should not have matched")
r5.MatchAny = append(r5.MatchAny,
MatchAnyElem{
MatchFeatures: FeatureMatcher{
FeatureMatcherTerm{
Feature: "domain-1.kf-1",
MatchExpressions: MatchExpressionSet{
Expressions: Expressions{"key-1": MustCreateMatchExpression(MatchExists)},
},
},
},
})
r5.MatchFeatures[0].MatchExpressions.Expressions["key-1"] = MustCreateMatchExpression(MatchIn, "val-1")
m, err = r5.Execute(f)
assert.Nilf(t, err, "unexpected error: %v", err)
assert.Equal(t, r5.Labels, m, "instances should have matched")
source/custom: implement generic feature matching Implement generic feature matchers that cover all feature sources (that implement the FeatureSource interface). The implementation relies on the unified data model provided by the FeatureSource interface as well as the generic expression-based rule processing framework that was added to the source/custom/expression package. With this patch any new features added will be automatically available for custom rules, without any additional work. Rule hierarchy follows the source/feature hierarchy by design. This patch introduces a new format for custom rule specifications, dropping the 'value' field and introducing new 'labels' field which makes it possible to specify multiple labels per rule. Also, in the new format the 'name' field is just for reference and no matching label is created. The new generic rules are available in this new rule format under a 'matchFeatures. MatchFeatures implements a logical AND over an array of per-feature matchers - i.e. a match for all of the matchers is required. The goal of the new rule format is to make it better follow K8s API design guidelines and make it extensible for future enhancements (e.g. addition of templating, taints, annotations, extended resources etc). The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID, usbID rules) is still supported. The rule format (new vs. old) is determined at config parsing time based on the existence of the 'matchOn' field. The new rule format and the configuration format for the new matchFeatures field is - name: <rule-name> labels: <key>: <value> ... matchFeatures: - feature: <domain>.<feature> matchExpressions: <attribute>: op: <operator> value: - <list-of-values> - feature: <domain>.<feature> ... Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources are covered by the matshers/feature selectors. Thus, the following features are available for matching with this patch: - cpu.cpuid: <cpuid-flag>: <exists/does-not-exist> - cpu.cstate: enabled: <bool> - cpu.pstate: status: <string> turbo: <bool> scaling_governor: <string> - cpu.rdt: <rdt-feature>: <exists/does-not-exist> - cpu.sst: bf.enabled: <bool> - cpu.topology: hardware_multithreading: <bool> - kernel.config: <flag-name>: <string> - kernel.loadedmodule: <module-name>: <exists/does-not-exist> - kernel.selinux: enabled: <bool> - kernel.version: major: <int> minor: <int> revision: <int> full: <string> - system.osrelease: <key-name>: <string> VERSION_ID.major: <int> VERSION_ID.minor: <int> - system.name: nodename: <string> - pci.device: <device-instance>: class: <string> vendor: <string> device: <string> subsystem_vendor: <string> susbystem_device: <string> sriov_totalvfs: <int> - usb.device: <device-instance>: class: <string> vendor: <string> device: <string> serial: <string> - local.label: <label-name>: <string> The configuration also supports some "shortforms" for convenience: matchExpressions: [<attr-1>, <attr-2>=<val-2>] --- matchExpressions: <attr-3>: <attr-4>: <val-4> is equal to: matchExpressions: <attr-1>: {op: Exists} <attr-2>: {op: In, value: [<val-2>]} --- matchExpressions: <attr-3>: {op: Exists} <attr-4>: {op: In, value: [<val-4>]} In other words: - feature: kernel.config matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"] - feature: pci.device matchExpressions: vendor: "8086" is the same as: - feature: kernel.config matchExpressions: X86: {op: Exists} INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]} - feature: pci.device matchExpressions: vendor: {op: In, value: ["8086"] Some configuration examples below. In order to match a CPUID feature the following snippet can be used: - name: cpu-test-1 labels: cpu-custom-feature: "true" matchFeatures: - feature: cpu.cpuid matchExpressions: AESNI: {op: Exists} AVX: {op: Exists} In order to match against a loaded kernel module and OS version: - name: kernel-test-1 labels: kernel-custom-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: e1000: {op: Exists} - feature: system.osrelease matchExpressions: NAME: {op: InRegexp, values: ["^openSUSE"]} VERSION_ID.major: {op: Gt, values: ["14"]} In order to require a kernel module and both of two specific PCI devices: - name: multi-device-test labels: multi-device-feature: "true" matchFeatures: - feature: kernel.loadedmodule matchExpressions: driver-module: {op: Exists} - pci.device: vendor: "8086" device: "1234" - pci.device: vendor: "8086" device: "abcd"
2021-10-14 10:22:07 +03:00
}