[RFC] add udevadm & udev facts

[jhoblitt]

I want to be able to identify / construct the /dev/disk/by-id/<foo> paths for nvme devices on Linux to be used in EL kickstart scripts and have been unable to identify an existing fact which makes this data available.

The approach taken with the udev fact is to dump the entire udev dev db as it seems likely that there will be other uses for this data. Devices without a /dev/<foo> file are filtered out (E.g. ACPI devices). Even with filtering, this is a fairly large structured fact as the data describes every file under /dev.

QUESTION(S):

• Is this module the correct place for these facts?
• Is there a use case for information on devices which do not have a block/special file?
• Is the data structure of this fact reasonable?
• Should the /dev devices be moved under a sub hash key such as udev::dev::<device name> to allow for all devices to be exposed as udev::path::<device> in the future?

Example CLI usage of the `udev fact:

$ FACTERLIB=$(pwd)/lib/facter be facter udev.nvme0n1
{
  name => "nvme0n1",
  path => "/devices/pci0000:00/0000:00:01.0/0000:01:00.0/nvme/nvme0/nvme0n1",
  priority => 0,
  property => {
    CURRENT_TAGS => ":systemd:",
    DEVLINKS => [
      "/dev/disk/by-id/nvme-Samsung_SSD_960_EVO_1TB_S3ETNX0J208970A",
      "/dev/disk/by-path/pci-0000:01:00.0-nvme-1",
      "/dev/disk/by-id/nvme-eui.0025385271b166c9"
    ],
    DEVNAME => "/dev/nvme0n1",
    DEVPATH => "/devices/pci0000:00/0000:00:01.0/0000:01:00.0/nvme/nvme0/nvme0n1",
    DEVTYPE => "disk",
    DISKSEQ => "3",
    ID_MODEL => "Samsung SSD 960 EVO 1TB",
    ID_PART_TABLE_TYPE => "gpt",
    ID_PART_TABLE_UUID => "369c0ca0-758a-44d5-abe3-0d81c7a73b51",
    ID_PATH => "pci-0000:01:00.0-nvme-1",
    ID_PATH_TAG => "pci-0000_01_00_0-nvme-1",
    ID_REVISION => "2B7QCXE7",
    ID_SERIAL => "Samsung_SSD_960_EVO_1TB_S3ETNX0J208970A",
    ID_SERIAL_SHORT => "S3ETNX0J208970A",
    ID_WWN => "eui.0025385271b166c9",
    MAJOR => "259",
    MINOR => "0",
    SUBSYSTEM => "block",
    TAGS => ":systemd:",
    USEC_INITIALIZED => "63550668378"
  },
  symlink => [
    "disk/by-id/nvme-Samsung_SSD_960_EVO_1TB_S3ETNX0J208970A",
    "disk/by-path/pci-0000:01:00.0-nvme-1",
    "disk/by-id/nvme-eui.0025385271b166c9"
  ]
}
$ FACTERLIB=$(pwd)/lib/facter be facter udev.nvme0n1.symlink
[
  "disk/by-path/pci-0000:01:00.0-nvme-1",
  "disk/by-id/nvme-Samsung_SSD_960_EVO_1TB_S3ETNX0J208970A",
  "disk/by-id/nvme-eui.0025385271b166c9"
$ FACTERLIB=$(pwd)/lib/facter be facter udev.nvme0n1.property.DEVLINKS
[
  "/dev/disk/by-id/nvme-Samsung_SSD_960_EVO_1TB_S3ETNX0J208970A",
  "/dev/disk/by-id/nvme-eui.0025385271b166c9",
  "/dev/disk/by-path/pci-0000:01:00.0-nvme-1"
]
$ FACTERLIB=$(pwd)/lib/facter be facter udev.nvme0n1.property.ID_SERIAL
Samsung_SSD_960_EVO_1TB_S3ETNX0J208970A

[jcpunk]

Should the /dev devices be moved under a sub hash key such as udev::dev:: to allow for all devices to be exposed as udev::path:: in the future?

I'd prefer to have the udev::dev and udev::path options available going forward.

I'd love to have these natively in facter, but it can take a long time for those to get out to folks whereas this would be a lot faster....

[jhoblitt]

I'm concerned that adding all of the path entries is going to slow the fact down but I'm willing give it a try.

[jhoblitt]

I've added a test fixture for EL9.

[jhoblitt]

It looks like fedora 37 uses more letter codes than EL7/8/9. I'm looking into adding support for the extra codes.

[jhoblitt]

@jcpunk @bastelfreak I have added a seperate name and path index as udev::{name,path}. Is this what you had in mind?

Interestingly, the facter cli doesn't seem to have a mechanism for escaping . in fact names. E.g.:

$ FACTERLIB=$(pwd)/lib/facter be facter udev.name.nvme0n1
{
  name => "nvme0n1",
  path => "/devices/pci0000:00/0000:00:01.0/0000:01:00.0/nvme/nvme0/nvme0n1",
  priority => 0,
  property => {
    CURRENT_TAGS => ":systemd:",
    DEVLINKS => [
      "/dev/disk/by-diskseq/3",
      "/dev/disk/by-path/pci-0000:01:00.0-nvme-1",
      "/dev/disk/by-id/nvme-Samsung_SSD_960_EVO_1TB_S3ETNX0J208970A",
      "/dev/disk/by-id/nvme-eui.0025385271b166c9"
    ],
    DEVNAME => "/dev/nvme0n1",
    DEVPATH => "/devices/pci0000:00/0000:00:01.0/0000:01:00.0/nvme/nvme0/nvme0n1",
    DEVTYPE => "disk",
    DISKSEQ => "3",
    ID_MODEL => "Samsung SSD 960 EVO 1TB",
    ID_PART_TABLE_TYPE => "gpt",
    ID_PART_TABLE_UUID => "369c0ca0-758a-44d5-abe3-0d81c7a73b51",
    ID_PATH => "pci-0000:01:00.0-nvme-1",
    ID_PATH_TAG => "pci-0000_01_00_0-nvme-1",
    ID_REVISION => "2B7QCXE7",
    ID_SERIAL => "Samsung_SSD_960_EVO_1TB_S3ETNX0J208970A",
    ID_SERIAL_SHORT => "S3ETNX0J208970A",
    ID_WWN => "eui.0025385271b166c9",
    MAJOR => "259",
    MINOR => "0",
    SUBSYSTEM => "block",
    TAGS => ":systemd:",
    USEC_INITIALIZED => "17952026"
  },
  symlink => [
    "disk/by-diskseq/3",
    "disk/by-path/pci-0000:01:00.0-nvme-1",
    "disk/by-id/nvme-Samsung_SSD_960_EVO_1TB_S3ETNX0J208970A",
    "disk/by-id/nvme-eui.0025385271b166c9"
  ]
}
$ FACTERLIB=$(pwd)/lib/facter be facter udev.path./devices/virtual/vc/vcsu
{
  name => "vcsu",
  path => "/devices/virtual/vc/vcsu",
  priority => 0,
  property => {
    DEVNAME => "/dev/vcsu",
    DEVPATH => "/devices/virtual/vc/vcsu",
    MAJOR => "7",
    MINOR => "64",
    SUBSYSTEM => "vc"
  }
}
$ FACTERLIB=$(pwd)/lib/facter be facter udev.path./devices/pci0000:00/0000:00:01.0/0000:01:00.0/nvme/nvme0/nvme0n1

$ FACTERLIB=$(pwd)/lib/facter be facter udev.path./devices/pci0000:00/0000:00:01\\.0/0000:01:00\\.0/nvme/nvme0/nvme0n1

[jcpunk]

That looks awesome to me.

[jhoblitt]

I have added support for the all of the additional letter codes present on my f37 desktop. There are still a few unsupported code but I'd like to have a real world test fixture for them before adding support.

[deemon87]

I have question. What the reason to get udevadm facts? For example on some hosts count of facts increase on 25k+ I think it is no good. Do you think if i have 100 or 1000 hosts and i will get 25k+ facts from each one is it ok?