/dev
directory, such as microphones, security chips, usb cameras, and so on. Udev can be used to find devices that are attached to or embedded in Linux nodes.agent.full=true
is set. By default, a slim Agent without any embedded Discovery Handlers is deployed and the required Discovery Handlers can be deployed as DaemonSets. This documentation will use that strategy, deploying udev Discovery Handlers by specifying udev.discovery.enabled=true
when installing Akri.helm inspect values akri-helm-charts/akri
). To apply the udev Configuration to your cluster, simply set udev.configuration.enabled=true
when installing Akri. Be sure to also specify one or more udev rules for the Configuration, as explained below.IMPORT
in the udev rules. You should only use match operations ("==", "!=") and the following udev fields: ATTRIBUTE
, ATTRIBUTE
, DEVPATH
, DRIVER
, DRIVERS
, KERNEL
, KERNELS
, ENV
, SUBSYSTEM
, SUBSYSTEMS
, TAG
, and TAGS
. To see some examples, reference our example supported rules and unsupported rules that we run some tests against.brokerPod
) in the Configuration. Alternatively, if it meets your scenario, you could use the Akri frame server broker ("ghcr.io/project-akri/akri/udev-video-broker"). If you would rather manually deploy pods to utilize the cameras advertized by Akri, don't specify a broker pod and see our documentation on requesting resources advertized by Akri.Note only abrokerJob
ORbrokerPod
should be specified.
brokerJob
) in the Configuration. A Kubernetes Job deploys a set number of terminating Pods.Note only abrokerJob
ORbrokerPod
should be specified.
OnFailure
RestartPolicy
for the Job. Can either be OnFailure
or Never
for Jobs.udev.configuration.capacity
setting to reflect the correct number. For example, if your high availability needs are met by having 1 redundant pod, you can update the Configuration like this by setting udev.configuration.capacity=2
.udevadm
. For example, to find all devices in the sound subsystem, you could run:udevadm info
:Great Vendor
. You set the following udev rule under the udev Discovery Handler in your Configuration:90-akri.rules
in the /etc/udev/rules.d
directory, and add your udev rule(s) to it. For this example, we will be testing the rule SUBSYSTEM=="sound", KERNEL=="card[0-9]*"
. Add TAG+="akri_tag"
to the end of each rule. Note how 90 is the prefix to the file name. This makes sure these rules are run after the others in the default 70-snap.core.rules
, preventing them from being overwritten. Feel free to explore 70-snap.core.rules
to see numerous examples of udev rules./dev
directory). These device node paths will be mounted into broker Pods so the brokers can utilize the devices.+=
turns to -=
-- and reload and trigger the udev rules. Alternatively, if you are trying to discover devices with fields that Akri does not yet support, such as ATTRS
, you could leave the tag and add it to the rule in your Configuration with TAG=="akri_tag"
.Note: See the cluster setup steps for information on how to set the crictl configuration variableAKRI_HELM_CRICTL_CONFIGURATION
kubectl get akrii
. Note akrii
is a short name for Akri Instance. All the instances will be named in the format <configuration-name>-<hash>
. You could change the name of the Configuration and resultant Instances to be sound-device
by adding --set udev.configuration.name=sound-devices
to your installation command. Now, you can schedule pods that request these Instances as resources, as explained in the requesting akri resources document.UDEV_DEVNODE
which contains the devnode path for that device (ie: /dev/snd/pcmC0D0c
). The broker can grab this environment variable and proceed to interact with the device. To add a broker to the udev configuration, set the udev.configuration.brokerPod.image.repository
value to point to your image. As an example, the installation below will deploy an empty nginx pod for each instance. Instead, you can point to your image, say ghcr.io/<USERNAME>/sound-broker
.Note: setudev.configuration.brokerPod.image.tag
to specify an image tag (defaults tolatest
).
ATTR
and TAG
), which are yet to be supported (ATTRS
and TAGS
), and which fields will never be supported, mainly due to be assignment rather than matching fields (such as ACTION
and GOTO
).