Allow to have optional devices

[SuperTux88]

I have a use-case which I couldn't solve with the current version of the generic-device-plugin, because I have a container that I need to deploy of a lot of different target hosts. The hosts have one or multiple serial devices connected, but not always with the same paths. Some are connected directly to the ttyS0, while others are connected via a USB-adapter ttyUSB0. And the existence of the path doesn't say anything about if there is actually a serial device connected to it, it just means that the serial interface is there. So the ttyS0 is always there, even if the serial device is connected via USB, and some hosts have multiple serial devices connected to it, while others have only one connected (some only ttyS0, some only ttyUSB0 or only ttyUSB1, while others maybe have both USB devices connected).

The software running inside the container already handles this correctly, as it just probes all possible interfaces and checks on which of them something is connected (in the past it had to do the same running natively on the host, where also just all possible interfaces existed). So I just need to mount all existing devices on the host also to the container, and the software inside the container then handles the rest.

With the current version I wasn't able to achieve this, because if I define all paths, it only worked on the hosts where at least all serial interfaces are available (but didn't work on the hosts where the USB-interfaces were missing), and if I define them with a wildcard path or with multiple groups, it just mounted one of the paths, which might be the correct one, but often wasn't (and especially didn't work on the hosts with multiple serial devices connected).

This patch now allows me to use a config like this:

  - name: serial
    groups:
      - paths:
          - path: /dev/ttyS0
            optional: true
          - path: /dev/ttyUSB0
            optional: true
          - path: /dev/ttyUSB1
            optional: true

This then mounts all paths that are available, but ignores the ones that are missing (which doesn't block starting the container because some resources are missing). So it solves my use-case.

What it doesn't do is, handling dynamically adding or removing devices after the container was started. But in my case the hardware is static (so devices don't get plugged or unplugged during runtime). But since the generic-device-plugin already scans for which devices are available, all it would require is something outside of the generic-device-plugin that monitors devices changes on the host and then triggering a restart of the specific containers. So I think it's fine to not handle this inside the generic-device-plugin.

[squat]

Morally I understand that skipping errors for non-required devices should probably not block your container from starting but I wonder if this is necessary or if we want to be super strict and fail a bit more conservatively on errors.

[SuperTux88]

Yes you are right, this is not really needed, as I just checked the documentation again, and the only scenario where there should be an error is when the pattern is malformed ... and I think if you fuck up your pattern, it's OK to fail, even when optional. So I removed this again.

[SuperTux88]

I also fixed the missing part in the readme, so CI should hopefully also be happy now 😃