Duplicate blank broker pod appearing for a single camera device on K3d

[rupipal]

Hi,
Following the getting started ( https://docs.akri.sh/user-guide/getting-started), I could install the latest Akri release on a K3d cluster ( https://k3d.io/v5.2.1/ ) that I've named myk3-1.

Specifically, these are the steps I used.

export AKRI_HELM_CRICTL_CONFIGURATION="--set kubernetesDistro=k3s"
helm install akri akri-helm-charts/akri
$AKRI_HELM_CRICTL_CONFIGURATION
--set udev.discovery.enabled=true
--set udev.configuration.enabled=true
--set udev.configuration.discoveryDetails.udevRules[0]='KERNEL=="video[0-9]*"'
--set udev.configuration.brokerPod.image.repository=nginx

These are some outputs.

$ kubectl get pods,akric,akrii,services
NAME READY STATUS RESTARTS AGE
pod/akri-controller-deployment-776897c88f-hr9dv 1/1 Running 0 34m
pod/akri-udev-discovery-daemonset-jh24s 1/1 Running 0 34m
pod/akri-agent-daemonset-bzqd4 1/1 Running 0 34m
pod/akri-udev-f721a1-pod 1/1 Running 0 16m
pod/akri-udev-b275c5-pod 1/1 Running 0 16m

NAME CAPACITY AGE
configuration.akri.sh/akri-udev 1 34m

NAME CONFIG SHARED NODES AGE
instance.akri.sh/akri-udev-f721a1 akri-udev false ["k3d-myk3-1-server-0"] 16m
instance.akri.sh/akri-udev-b275c5 akri-udev false ["k3d-myk3-1-server-0"] 16m

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.43.0.1 443/TCP 44m
service/akri-udev-f721a1-svc ClusterIP 10.43.146.134 80/TCP 16m
service/akri-udev-svc ClusterIP 10.43.235.137 80/TCP 16m
service/akri-udev-b275c5-svc ClusterIP 10.43.9.86 80/TCP 16m

Whereas I have only one USB video device (camera) plugged in, I see to broker pods/instances. I checked--unplugging the camera causes both pods to go away. Inspecting each one gives; apparently one pod is correctly representation.

$ kubectl get akrii akri-udev-b275c5 -o yaml
apiVersion: akri.sh/v0
kind: Instance
metadata:
creationTimestamp: "2021-12-17T04:28:02Z"
generation: 2
name: akri-udev-b275c5
namespace: default
ownerReferences:

• apiVersion: akri.sh/v0
  blockOwnerDeletion: true
  controller: true
  kind: Configuration
  name: akri-udev
  uid: 69eb0109-5896-4f75-ad75-3ddf4cc69fe6
  resourceVersion: "2065"
  uid: a108d39f-96d1-4c58-90da-d1931d7843b8
  spec:
  brokerProperties:
  UDEV_DEVNODE: /dev/video0
  configurationName: akri-udev
  deviceUsage:
  akri-udev-b275c5-0: k3d-myk3-1-server-0
  nodes:
• k3d-myk3-1-server-0
  shared: false

kubectl get akrii udev-akri-udev-f721a1 -o yaml
Error from server (NotFound): instances.akri.sh "udev-akri-udev-f721a1" not found

Why are two instances seen for a single device?

regards
rps

[kate-goldenring]

Hi @rupipal, I've seen this in the past for USB cameras that have multiple device nodes for the single device, say /dev/video0 and /dev/video1. Can you do ls /dev/video*? I wonder if both dev nodes are needed for the camera to do what the broker needs. For example, if you change the rule to KERNEL=="video0" and use our custom broker ("ghcr.io/project-akri/akri/udev-video-broker"), does the broker execute without errors (looking at the logs)?

Regardless, this is something we need to address. How do we provide a filter/ parameter for udev that specifies multiple device nodes represent a device? Or how can we enable the discovery handler to detect that (in ideally a device agnostic way)? I wonder if we can inspect the device attributes (of each of /dev/video0 and /dev/video1) and see the difference (and relatedness)? What is the output of udevadm info --attribute-walk --path=$(udevadm info --query=name /dev/video0) and udevadm info --attribute-walk --path=$(udevadm info --query=name /dev/video1)?

[rupipal]

Hi Kate, Thanks for replying. Yes, initially, I too wondered if two broker pod instances are required. Will look into all that and will revert ASAP. BTW, I've raised another issue in Akri-on-Krustlet. I'm sure you would look into it. regards Rupinder

…

On Fri, Dec 17, 2021, 10:16 PM Kate Goldenring ***@***.***> wrote: Hi @rupipal <https://github.com/rupipal>, I've seen this in the past for USB cameras that have multiple device nodes for the single device, say /dev/video0 and /dev/video1. Can you do ls /dev/video*? I wonder if both dev nodes are needed for the camera to do what the broker needs. For example, if you change the rule to KERNEL=="video0" and use our custom broker ("ghcr.io/project-akri/akri/udev-video-broker"), does the broker execute without errors (looking at the logs)? Regardless, this is something we need to address. How do we provide a filter/ parameter for udev that specifies multiple device nodes represent a device? Or how can we enable the discovery handler to detect that (in ideally a device agnostic way)? I wonder if we can inspect the device attributes <https://docs.akri.sh/discovery-handlers/udev#choosing-a-udev-rule> (of each of /dev/video0 and /dev/video1) and see the difference (and relatedness)? What is the output of udevadm info --attribute-walk --path=$(udevadm info --query=name /dev/video0) and udevadm info --attribute-walk --path=$(udevadm info --query=name /dev/video1)? — Reply to this email directly, view it on GitHub <#438 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGJIEWFEBPKMVBQCD6QK74TURNSNNANCNFSM5KH6OVMA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[bfjelds]

Some interesting links from a search (something like: udev single device multiple nodes):

• https://unix.stackexchange.com/questions/86728/udev-rule-to-match-multiple-node-usb-device
• https://unix.stackexchange.com/questions/512759/multiple-dev-video-for-one-physical-device
• https://askubuntu.com/questions/1171192/multiple-dev-video-devices-for-1-camera-causing-issue-with-udev-rules

An interesting excerpt from the last link (not sure of validity):

As noticed in this related question, the value of ATTR{index} differs when the device is the real cam or only metadata. One should use the rule ATTR{index}=="0" to get the real device.

[github-actions]

Issue has been automatically marked as stale due to inactivity for 90 days. Update the issue to remove label, otherwise it will be automatically closed.

[kate-goldenring]

Keeping this alive ... we should still investigate this via @bfjelds proposal #438 (comment)

[kate-goldenring]

Following up on this. Oftentimes with usb cameras, there may be multiple dev nodes for the camers (ie /dev/video0 and /dev/video1). All that should be discovered, however, is the camera with capture capabilities. Setting your discoveryDetails to --set udev.configuration.discoveryDetails.udevRules[0]='KERNEL=="video[0-9]*"\, ENV{ID_V4L_CAPABILITIES}==":capture:"' will ensure no duplicate nodes are discovered.

Note: for Akri versions v0.6.5 to v0.8.4 --set udev.discovery.host.udev=/run/udev needs to be added to the installation as well. see #476

[rupipal]

Thanks @kate-goldenring . Will check this out soon. Any further feedback on the other issue :) project-akri/akri-on-krustlet#4

Rupinder