UDEV and predictable resource ids

[febus982]

Is there a way to have a predictable naming strategy for the the UDEV_DEVNODE and UDEV_DEVPATH environment variables?

Using the hash to differentiate the different devices works as long as it's possible to list all the environment variables and parse all of their prefix.

When you want to run containers with existing software (e.g. ser2net or zigbee2mqtt) it's difficult to specify the correct environment variable in the manifest because of the final name being unknown.

I am using a single ser2net pod for a single USB device configuration and I'd need to pass the exact variable name (or the variable content) to the podspec.

Right now I'm using this approach in a container containing the ser2net but it's kind of an hacky one.

CMD export ADAPTER=$(env | awk -F= '/^UDEV_DEVNODE/ {print $2;exit;}') \
 && echo "\
connection: &con01\n\
  accepter: tcp,20108\n\
  connector: serialdev,$ADAPTER,115200n81,nobreak,local\n\
  options:\n\
    kickolduser: true\
" > /ser2netconfig/config.yaml \
 && echo -n "Starting " && ser2net -v && ser2net -d -c /ser2netconfig/config.yaml

Also the same device changes suffix if attached to different nodes, so it's impossible to schedule pods using a separate manifest simply by requesting akri resources.

Is there a way to have predictable resource ids instead of a hash? Or at least an hash that depends only on the physical device information so it remains consistent if attached to different nodes/usb_ports

[diconico07]

In order to have a predictable environment variable name you would need a predictable instance id.

However this would be difficult for udev as there are no unique identifier (other than node+device path), using something like vendor id/device id for a usb device wouldn't work if you have multiple of them.

For the "requesting akri resources" usecase, #565 will surely help you when out.

[febus982]

That PR would be great! Can't wait to see it merged.

I don't want to add further requirements but would it make sense to use the suffix in the env variable only when more than one device is identified by the instance?

[jbpaux]

For your first issue you can try to write your /ser2netconfig/config.yaml file using in your podspec an init container responsible to get the variable and build the file

[kate-goldenring]

That PR would be great! Can't wait to see it merged.

I don't want to add further requirements but would it make sense to use the suffix in the env variable only when more than one device is identified by the instance?

@febus982 this might be hard, but one thing we could do is always also set UDEV_DEVNODE and UDEV_DEVPATH for each device. It will be overwritten by each device and randomly contain one of the device's info, but for one device it would be accurate. A little hacky but maybe appropriate?

[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.

[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.