1
0
Fork 0
mirror of https://github.com/kubernetes-sigs/node-feature-discovery.git synced 2024-12-14 11:57:51 +00:00
Commit graph

56 commits

Author SHA1 Message Date
Carlos Eduardo Arango Gutierrez
3434557d7c
Move NFD api to a separate go mod
Signed-off-by: Carlos Eduardo Arango Gutierrez <eduardoa@nvidia.com>
2024-04-05 16:35:47 +02:00
Markus Lehtonen
97bf841140 apis/nfd: split rule processing into a separate package
This patch tidies up the nfdv1alpha1 API package by refactoring out the
implementation of (NodeFeature)Rule evaluation into a separate package.
2023-12-20 12:52:15 +02:00
Markus Lehtonen
a8092927fc source/custom: use internal api for config parsing
Change the custom feature source of nfd-worker to use the newly added
internal config API for its own configuration. It now uses the internal
types for json/yaml unmarshalling but converts them to external
nfdv1alpha1 API to do the actual rule matching as the internal API does
not duplicate that functionality.
2023-12-18 15:19:19 +02:00
Markus Lehtonen
185b406ee7 source/custom: add internal rule api
Add internal API for the nfd-worker custom feature source rule
configuration. This API has already diverged from the NFD
NodeFeatureRule API in that annotations, extended resources or taints
are not supported. This patch basically copies the Rule type (and it's
sub-types) from the nfdv1alpha1 package. It also adds conversion
functions from the internal rule API to the "external" nfdv1alpha1 API.
This is done to use the same rule matching functionality (from the
nfdv1alpha1 package).

One notable remark is that the feature source rule config supports some
custom formatting (short forms, multi-type fields) that relies on
special json/yaml unmarshalling functions that are better to nuke from
the nfdv1alpha1 package (in another patch). These (legacy) syntax
specialities are most probably used by nobody but let's keep them as
they're already there.  Unit tests to cover the custom json
unmarshalling are now added.
2023-12-18 15:19:19 +02:00
Markus Lehtonen
fe412a54b9 apis/nfd: add matchName field in feature matcher terms
Extend the format of feature matcher terms (the elements of the
arrayspecified under under matchFeatures field) with new matchName
field. The value of this field is an expression that is evaluated
against the names of feature elements instead of their values (values
are matched with the matchExpressions field, instead).

The matchName field is useful e.g. in template rules for creating
per-feature-element labels based on feature names (instead of values)
and in non-template rules for checking if (at least) one of certain
feature element names are present.

If both matchExpressions and matchName for certain feature matcher term
is specified, they both must match in order to get an overall match.
Also, in this case the list of matched features (used in templating) is
the union of the results from matchExpressions and matchName.

An example of creating an "avx512" label if any AVX512* CPUID feature is
present:

  - name: "avx wildcard rule"
    labels:
        avx512: "true"
    matchFeatures:
      - feature: cpu.cpuid
        matchName: {op: InRegexp, value: ["^AVX512"]}

An example of a template rule creating a dynamic set of labels  based on
the existence of certain kconfig options.

  - name: "kconfig template rule"
    labelsTemplate: |
      {{ range .kernel.config }}kconfig-{{ .Name }}={{ .Value }}
      {{ end }}
    matchFeatures:
      - feature: kernel.config
        matchName: {op: In, value: ["SWAP", "X86", "ARM"]}

NOTE: this patch changes the corner case of nil/null match expressions
with instance features (i.e. "matchExpressions: null"). Previously, we
returned all instances for templating but now a nil match expression is
not evaluated and no instances for templating are returned.
2023-12-15 11:32:23 +02:00
Markus Lehtonen
0bc1b6c28f apis/nfd: drop creation helper functions
Drop the creation helper functions as one step in an effort to tidy up
the api package. These functions were not much used outside unit tests
anyway, the static rules of the nfd-worker custom feature source being
the only exception (and if those happened to be invalid we'd catch that
e.g. in the e2e-tests).
2023-12-14 15:54:51 +02:00
Markus Lehtonen
7d1df87305 source/custom: drop support for the legacy rule format 2023-10-05 16:15:37 +03:00
Markus Lehtonen
b1b3061738 sources/custom: convert static rules to new format
Also add a log message warning about legacy rule format.
2023-09-06 14:29:56 +03:00
Markus Lehtonen
bf670de68d pkg/utils: migrate KlogDump to structured logging
Drop the KlogDump helper in favor of klog.InfoS. However, that patch
introduces a new DelayedDumper() helper to avoid processing
(marshalling) of object unless really evaluated by the logging function.
2023-05-31 14:43:08 +03:00
Markus Lehtonen
fe267a634b source: migrate to structured logging
The custom.d config file parsing is made a bit less verbose.
2023-05-31 14:43:08 +03:00
Markus Lehtonen
b907d07d7e apis/nfd: flatten the structure of features data type
Flatten the data structure that stores features, dropping the "domain"
level from the data model. That extra level of hierarchy brought little
benefit but just caused some extra complexity, instead. The new
structure nicely matches what we have in the NodeFeatureRule object (the
matchFeatures field of uses the same flat structure with the "feature"
field having a value <domain>.<feature>, e.g. "kernel.version").

This is pre-work for introducing a new "node feature" CRD that contains
the raw feature data. It makes the life of both users and developers
easier when both CRDs, plus our internal code, handle feature data in a
similar flat structure.
2022-10-18 18:37:28 +03:00
Markus Lehtonen
0e1d4a9046 apis/nfd: migrate pkg/api/feature
Move the previously-protobuf-only internal "feature api" over to the
public "nfd api" package. This is in preparation for introducing a new
CRD API for communicating features.

This patch carries no functional changes. Just moving code around.
2022-10-15 07:42:20 +03:00
Markus Lehtonen
abdbd420d1 pkg/api/feature: rename types
Sync type names with NFD documentation. Aims at making the codebase
easier to follow.
2022-10-06 11:25:01 +03:00
Markus Lehtonen
12e859d50c Drop deprecated io/ioutil package
Makes golanci-lint happy.
2022-09-08 14:26:02 +03:00
Markus Lehtonen
345e9bf72c apis/nfd: revert the type hack
Revert the hack that was a workaround for issues with k8s deepcopy-gen.
New deepcopy-gen is able to generate code correctly without issues so
this is not needed anymore.

Also, removing this hack solves issues with object validation when
creating NodeFeatureRules programmatically with nfd go-client. This is
needed later with NodeFeatureRules e2e-tests.

Logically reverts f3cc109f99.
2022-08-10 14:24:33 +03:00
Dipto Chakrabarty
19a57789ad
Additional Lint Fixes in Codebase (#779)
* fix comments and conditonals to fix lint issues

* more linter fixes and spelling fixes

* fix linter issues based on feedback
2022-03-02 17:12:46 -08:00
Dipto Chakrabarty
755294184c
Fix GoLinter Issues in the files (#711)
* fix linter issues for few files

* fix linter issue of exported const Name should have comment or be unexported

* fix name lint issue and resolve lints

* add changes to comments
2022-01-18 23:12:06 -08:00
Markus Lehtonen
bf01875368 nfd-worker: drop 'custom-' prefix from matchFeatures custom rules
Do not prefix label names from the new matchFeatures/matchAny custom
rules with "custom-". We want to have the same result (set of labels)
from a rule independent of whether it has been specified in worker
config or in a NodeFeatureRule CRs. Legacy matchOn rules (not available
in NodeFeatureRule CRs) are intact, i.e. still prefixed, in order to
retain backwards compatibility.
2021-12-09 21:52:40 +02:00
Markus Lehtonen
6f881a4822 source/kernel: unmangled kconfig values for custom rules
Stop converting "=y" and "=m" to "true" for the raw feature values used
in "kernel.config" custom rule processing.

In practice, this means that to check if a kernel config flag has been
set to "y" or "m", one needs to explicitly check for both of the values:

  matchFeatures:
    - feature: kernel.config
      matchExpressions:
        FOO: {op: In, value: ["y", "m"]}

instead of (how it used to be):

  matchFeatures:
    - feature: kernel.config
      matchExpressions:
        FOO: {op: IsTrue}

The legacy kconfig custom rule is unchanged as are the
kernel-config.<flag> feature labels.
2021-12-02 10:06:21 +02:00
Markus Lehtonen
f75303ce43 pkg/apis/nfd: add variables to rule spec and support backreferences
Support backreferencing of output values from previous rules. Enables
complex rule setups where custom features are further combined together
to form even more sophisticated higher level labels. The labels created
by preceding rules are available as a special 'rule.matched' feature
(for matchFeatures to use).

If referencing rules accross multiple configs/CRDs care must be taken
with the ordering. Processing order of rules in nfd-worker:

1. Static rules
2. Files from /etc/kubernetes/node-feature-discovery/custom.d/
   in alphabetical order. Subdirectories are processed by reading their
   files in alphabetical order.
3. Custom rules from main nfd-worker.conf

In nfd-master, NodeFeatureRule objects are processed in alphabetical
order (based on their metadata.name).

This patch also adds new 'vars' fields to the rule spec. Like 'labels',
it is a map of key-value pairs but no labels are generated from these.
The values specified in 'vars' are only added for backreferencing into
the 'rules.matched' feature. This may by desired in schemes where the
output of certain rules is only used as intermediate variables for other
rules and no labels out of these are wanted.

An example setup:

  - name: "kernel feature"
    labels:
      kernel-feature:
    matchFeatures:
      - feature: kernel.version
        matchExpressions:
          major: {op: Gt, value: ["4"]}

  - name: "intermediate var feature"
    vars:
      nolabel-feature: "true"
    matchFeatures:
      - feature: cpu.cpuid
        matchExpressions:
          AVX512F: {op: Exists}
      - feature: pci.device
        matchExpressions:
          vendor: {op: In, value: ["8086"]}
          device: {op: In, value: ["1234", "1235"]}

  - name: top-level-feature
    matchFeatures:
      - feature: rule.matched
        matchExpressions:
          kernel-feature: "true"
          nolabel-feature: "true"
2021-11-25 12:50:47 +02:00
Markus Lehtonen
8b9df3cf31 source/custom: move rule matching to pkg/apis/nfd
Move the rule processing of matchFeatures and matchAny from
source/custom package over to pkg/apis/nfd, aiming for better integrity
and re-usability of the code. Does not change the CRD API as such, just
adds more supportive functions.
2021-11-17 14:02:00 +02:00
Markus Lehtonen
f3cc109f99 pkg/apis/nfd: work around issues with k8s deepcopy-gen
Without this hack the generated code does not compile.
2021-11-17 13:40:43 +02:00
Markus Lehtonen
0757248055 source/custom: move rule expressions to pkg/apis/nfd/v1alpha1
Create a new package pkg/apis/nfd/v1alpha1 and migrate the custom rule
expressions over there. This is the first step in creating a new CRD API
for custom rules.
2021-11-16 18:12:16 +02:00
Markus Lehtonen
52d9aa2244 source/custom: improved logging of expression matching
Print out the result of applying an expression. Also, truncate the
output to max 10 elements (of items matched against) unless '-v 4'
verbosity level is in use.
2021-11-12 16:51:30 +02:00
Markus Lehtonen
6cbed379df source/custom: implement matchAny directive
Implement a new 'matchAny' directive in the new rule format, building on
top of the previously implemented 'matchFeatures' matcher. MatchAny
applies a logical OR over multiple matchFeatures directives. That is, it
allows specifying multiple alternative matchers (at least one of which
must match) in a single label rule.

The configuration format for the new matchers is

  matchAny:
    - matchFeatures:
        - feature: <domain>.<feature>
          matchExpressions:
            <attribute>:
              op: <operator>
              value:
                - <list-of-values>
    - matchFeatures:
      ...

A configuration example. In order to require a cpu feature, kernel
module and one of two specific PCI devices (taking use of the shortform
notation):

  - name: multi-device-test
    labels:
      multi-device-feature: "true"
    matchFeatures:
      - feature: kernel.loadedmodule
        matchExpressions: [driver-module]
      - feature: cpu.cpuid
        matchExpressions: [AVX512F]
    matchAny:
      - matchFeatures:
          - feature; pci.device
            matchExpressions:
              vendor: "8086"
              device: "1234"
      - matchFeatures:
          - feature: pci.device
            matchExpressions:
              vendor: "8086"
              device: "abcd"
2021-11-12 16:51:30 +02:00
Markus Lehtonen
e206f0b86b 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-11-12 16:51:13 +02:00
Markus Lehtonen
689703be48 source/custom: implement 'GtLt' operator
A new operator for checking that an input (integer) is between two
values.
2021-11-11 19:59:34 +02:00
Markus Lehtonen
8b4314bbbb source/custom: expression based label rules
Implement a framework for more flexible rule configuration and matching,
mimicking the MatchExpressions pattern from K8s nodeselector.

The basic building block is MatchExpression which contains an operator
and a list of values. The operator specifies that "function" that is
applied when evaluating a given input agains the list of values.
Available operators are:

- MatchIn
- MatchNotIn
- MatchInRegexp
- MatchExists
- MatchDoesNotExist
- MatchGt
- MatchLt
- MatchIsTrue
- MatchIsFalse

Another building block of the framework is MatchExpressionSet which is a
map of string-MatchExpression pairs. It is a helper for specifying
multiple expressions that can be matched against a set of set of
features.

This patch converts all existing custom rules to utilize the new
expression-based framework.
2021-11-11 19:59:34 +02:00
Markus Lehtonen
e225f4aad0 source/system: implement FeatureSource
Separate feature discovery and creation of feature labels in the system
source.

Also, change the implementation of the nodeName custom rule to utilize
the FeatureSource interface of the system source.

Also, add minimalist unit test.
2021-11-11 18:33:58 +02:00
Markus Lehtonen
5cf25dc4e9 source/custom: move kernel module detection to source/kernel
Move the functionality responsible for detection of loeaded kernel
modules from source/custom over to the source/kernel package. Add a new
"loadedmodule" raw feature to the kernel source to store this
information.

Change loadedKmod custom rule to utilize kernel source.
2021-11-11 18:33:58 +02:00
Markus Lehtonen
df27327f14 source/usb: implement FeatureSource
Separate feature discovery and creation of feature labels in the usb
source.

Move usb_utils from source/internal to the source/usb package. Change
the implementation of the UsbID custom rule to utilize the FeatureSource
interface of the usb source.

Also, add minimalist unit test.
2021-11-11 18:33:53 +02:00
Markus Lehtonen
af0c683f60 source/pci: implement FeatureSource
Separate feature discovery and creation of feature labels in the pci
source.

Move pci_utils from source/internal to the source/pci package. Change
the implementation of the PciID custom rule to utilize the FeatureSource
interface of the pci source.

Also, add minimalist unit test.
2021-11-11 18:33:53 +02:00
Markus Lehtonen
03bf94a8ad source/cpu: implement FeatureSource
Convert the cpu source to do feature discovery and creation of feature
labels separately.

Move cpuidutils from source/internal to the source/cpu package. Change
the cpuid custom rule to utilize GetFeatures of the cpu source.

Also, add minimalist unit test.
2021-11-11 18:33:40 +02:00
Markus Lehtonen
0945019161 source/kernel: implement FeatureSource
Separate feature discovery and creation of feature labels in the kernel
source.

Move kernelutils from source/internal back to the source/kernel package.
Change the kconfig custom rule to rely on the FeatureSource interface
(GetFeatures()) of the kernel source.

Also, add minimalist unit test.
2021-11-11 18:33:40 +02:00
Markus Lehtonen
852cf4b61d source: introduce FeatureSource interface
Specify a new interface for managing "raw" feature data. This is the
first step to separate raw feature data from node labels. None of the
feature sources implement this interface, yet.

This patch unifies the data format of "raw" features by dividing them
into three different basic types.
- keys, a set of names without any associated values, e.g. CPUID flags
  or loaded kernel modules
- values, a map of key-value pairs, for features with a single value,
  e.g. kernel config flags or os version
- instances, a list of instances each of which has multiple attributes
  (key-value pairs of their own), e.g. PCI or USB devices

The new feature data types are defined in a new "pkg/api/feature"
package, catering decoupling and re-usability of code e.g. within future
extentions of the NFD gRPC API.

Rename the Discover() method of LabelSource interface to GetLabels().
2021-09-20 09:58:07 +03:00
Markus Lehtonen
81378a3235 source: make sources register themselves
Implement new registration infrastructure under the "source" package.
This change loosens the coupling between label sources and the
nfd-worker, making it easier to refactor and move the code around.

Also, create a separate interface (ConfigurableSource) for configurable
feature sources in order to eliminate boilerplate code.

Add safety checks to the sources that they actually implement the
interfaces they should.

In sake of consistency and predictability (of behavior) change all
methods of the sources to use pointer receivers.

Add simple unit tests for the new functionality and include source/...
into make test target.
2021-09-15 18:41:37 +03:00
Markus Lehtonen
befa7e9796 source: rename FeatureSource to LabelSource
Prepare for separating feature detection from label creation.
2021-09-13 22:48:33 +03:00
Kubernetes Prow Robot
e16d4c9b20
Merge pull request #543 from marquiz/devel/custom-kconfig-refactor
source/custom: refactor kconfig rule internal representation
2021-08-24 06:45:14 -07:00
Markus Lehtonen
a55783d533 Straighten wrinkles in lint fixes
Fix small mistakes that slipped through with lint fixes (in
1230945564).
2021-07-07 14:32:11 +03:00
Markus Lehtonen
aca9e3efb8 source/custom: refactor kconfig rule internal representation
Use a more well-defined form with separate key and value fields.
2021-07-07 10:43:25 +03:00
Carlos Eduardo Arango Gutierrez
1230945564
make golint happy
Signed-off-by: Carlos Eduardo Arango Gutierrez <carangog@redhat.com>
2021-06-14 12:27:58 -05:00
Carlos Eduardo Arango Gutierrez
894b7901ff
make gofmt happy by running gofmt -s
Signed-off-by: Carlos Eduardo Arango Gutierrez <carangog@redhat.com>
2021-06-14 12:24:44 -05:00
Markus Lehtonen
610b1c696c source: define source names as consts
Paves the way for future work on more general representation of
feature data and looser coupling of the data and feature source
interface.
2021-06-11 15:29:57 +03:00
Jorik Jonker
d857f88d2d Add support for using USB device serial number
In my homelab, I have different FTDI serial converters connected to
several utility meters. They all have identical vendor/device, but
different serials.

In order to detect a specific FTDI unit (eg.  the one connected to my
electricity meter), I'd like feature labels triggered by a specific USB
serial.

Signed-off-by: Jorik Jonker <jorik@kippendief.biz>
2021-05-06 13:34:39 +00:00
Markus Lehtonen
011954e4c4 source/custom: dump config in more human-readable form
Also, increase the verbosity level to 2 because this can produce quite a
bunch of log message lines.
2021-03-16 07:06:28 +02:00
Markus Lehtonen
7da7fde8f6 nfd-worker: switch to klog
Greatly expands logging capabilities and flexibility with verbosity
options, among other things.
2021-02-25 16:10:43 +02:00
Marc Sluiter
7038e49d02
source/custom: Add nodename rule
There are cases when the only available metadata for discovering
features is the node's name. The "nodename" rule extends the custom
source and matches when the node's name matches one of the given
nodename regexp patterns.
It is also possible now to set an optional "value" on custom rules,
which overrides the default "true" label value in case the rule matches.
In order to allow more dynamic configurations without having to modify
the complete worker configuration, custom rules are additionally read
from a "custom.d" directory now. Typically that directory will be filled
by mounting one or more ConfigMaps.

Signed-off-by: Marc Sluiter <msluiter@redhat.com>
2021-02-24 16:26:35 +01:00
Mikko Ylinen
e2ee7c6fca source/custom: add rules for cpuid and kconfig
Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>
2020-09-14 12:07:35 +03:00
Mikko Ylinen
d1cce3ba29 source/custom: do not return on rule errors
Skip to the next rule instead of returning immediately on
rule errors. For instance, if the static rules failed, user
provided rules would never be processed.

Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>
2020-09-14 12:07:35 +03:00
Markus Lehtonen
a2b9df5cd3 nfd-worker: rework configuration handling
Extend the FeatureSource interface with new methods for configuration
handling. This enables easier on-the fly reconfiguration of the
feature sources. Further, it simplifies adding config support to feature
sources in the future. Stub methods are added to sources that do not
currently have any configurability.

The patch fixes some (corner) cases with the overrides (--options)
handling, too:
- Overrides were not applied if config file was missing or its parsing
  failed
- Overrides for a certain source did not have effect if an empty config
  for the source was specified in the config file. This was caused by
  the first pass of parsing (config file) setting a nil pointer to the
  source-specific config, effectively detaching it from the main config.
  The second pass would then create a new instance of the source
  specific config, but, this was not visible in the feature source, of
  course.
2020-05-21 00:59:37 +03:00