Merge pull request #40 from kate-goldenring/remove-udev-directory-note

Remove recommedation to mount `/run/udev` directory

docs/demos/usb-camera-demo-rpi4.md

@@ -202,7 +202,7 @@ Look at the Configuration and Instances in more detail.
 
 ## Going beyond the demo
 
-1. Plug in real cameras! You can [pass environment variables](../development/broker-development.md#Specifying-additional-broker-environment-variables-in-a-Configuration) to the frame server broker to specify the format, resolution width/height, and frames per second of your cameras. Note, if not able to discover cameras, mount the udev directory into the discovery handlers by adding `--set udev.discovery.host.udev=/run/udev` to the installation.
+1. Plug in real cameras! You can [pass environment variables](../development/broker-development.md#Specifying-additional-broker-environment-variables-in-a-Configuration) to the frame server broker to specify the format, resolution width/height, and frames per second of your cameras.
 2. Apply the [ONVIF Configuration](../discovery-handlers/onvif.md) and make the streaming app display footage from both the local video devices and onvif cameras. To do this, modify the [video streaming yaml](https://github.com/project-akri/akri/blob/main/deployment/samples/akri-video-streaming-app.yaml) as described in the inline comments in order to create a larger service that aggregates the output from both the `udev-camera-svc` service and `onvif-camera-svc` service.
 3. Add more nodes to the cluster.
 4. Modify the udev rule to find a more specific subset of cameras

docs/demos/usb-camera-demo.md

@@ -258,7 +258,7 @@ After installing Akri, since the /dev/video1 and /dev/video2 devices are running
 
 ## Going beyond the demo
 
-1. Plug in real cameras! You can [pass environment variables](../development/broker-development.md#Specifying-additional-broker-environment-variables-in-a-Configuration) to the frame server broker to specify the format, resolution width/height, and frames per second of your cameras. Note, if not able to discover cameras, mount the udev directory into the discovery handlers by adding `--set udev.discovery.host.udev=/run/udev` to the installation.
+1. Plug in real cameras! You can [pass environment variables](../development/broker-development.md#Specifying-additional-broker-environment-variables-in-a-Configuration) to the frame server broker to specify the format, resolution width/height, and frames per second of your cameras.
 2. Apply the [ONVIF Configuration](../discovery-handlers/onvif.md) and make the streaming app display footage from both the local video devices and onvif cameras. To do this, modify the [video streaming yaml](https://github.com/project-akri/akri/blob/main/deployment/samples/akri-video-streaming-app.yaml) as described in the inline comments in order to create a larger service that aggregates the output from both the `udev-camera-svc` service and `onvif-camera-svc` service.
 3. Add more nodes to the cluster.
 4. Modify the udev rule to find a more specific subset of cameras

docs/discovery-handlers/udev.md

@@ -10,8 +10,6 @@ All of Akri's components can be deployed by specifying values in its Helm chart
 
 In order for the Agent to discover udev devices, a udev Discovery Handler must exist. Akri supports an Agent image that includes all supported Discovery Handlers. This Agent will be used if `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.
 
-> Note: if not able to discover the udev devices, mount the udev directory into the discovery handlers by adding `--set udev.discovery.host.udev=/run/udev` to the installation.
-
 ## udev Configuration Settings
 
 Instead of having to assemble your own udev Configuration yaml, we have provided a [Helm template](https://github.com/project-akri/akri/blob/main/deployment/helm/templates/udev-configuration.yaml). Helm allows us to parametrize the commonly modified fields in our configuration files, and we have provided many for udev (to see them, run `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](#discovery-handler-discovery-details-settings).
@@ -166,8 +164,6 @@ helm install akri akri-helm-charts/akri \
     --set udev.configuration.discoveryDetails.udevRules[0]='SUBSYSTEM=="sound"\, ATTR{vendor}=="Great Vendor"'
 ```
 
-> Note: if not able to discover the udev devices, mount the udev directory into the discovery handlers by adding `--set udev.discovery.host.udev=/run/udev` to the installation.
-
 The following installation examples have been given to show how to the udev Configuration can be tailored to you cluster:
 
 * Modifying the udev rule
@@ -189,7 +185,6 @@ helm install akri akri-helm-charts/akri \
     --set udev.configuration.discoveryDetails.udevRules[1]='SUBSYSTEM=="sound"\, ATTR{vendor}=="Awesome Vendor"'
 ```
 
-> Note: if not able to discover the udev devices, mount the udev directory into the discovery handlers by adding `--set udev.discovery.host.udev=/run/udev` to the installation.
 Akri will now discover these devices and advertize them to the cluster as resources. Each discovered device is represented as an Akri Instance. To list them, run `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](../user-guide/requesting-akri-resources.md).
 
 ## Specifying a broker pod image