Client: Collect metrics from Local FCOS machines

[zonggen]

A top level TODO list for future fedora-coreos-pinger work:

Data collection:

minimal (default):

• [x] Platform (cloud environment or hypervisor)
• [x] Current OS version
• [x] Original OS version
• [x] On cloud systems, the instance type
  • Involves fetching instance type in Afterburn and read the fetched metadata
    • [x] AWS
    • [x] Azure
    • [x] CloudStack
    • [x] DigitalOcean
    • [x] GCP
    • [x] OpenStack
    • [x] Packet

full:

• [x] On bare-metal systems, a summary of hardware
• [x] Summary of network configuration
• [x] Container runtimes in use

Persistent state for timer:

• [x] Add DynamicUser= and StateDirectory= in service file

Reference:

• https://github.com/coreos/fedora-coreos-tracker/issues/86#issuecomment-453787136
• https://github.com/coreos/fedora-coreos-pinger/pull/29
• https://github.com/coreos/fedora-coreos-pinger/pull/35

[zonggen]

Will be breaking this card into three separate parts:

• Client data collection
• Server side data receiving and aggregating
• Protocol design

[zonggen]

For OS version, it is collected from /etc/os-release.

Collecting original OS version seems like it requires persistent state if we want to send the info about original OS version each time we are sending the data. On the other hand, make an OS version info persistent on disk doesn't sound secure (?), need someone to confirm if I understand this correctly.

[bgilbert]

Collecting original OS version seems like it requires persistent state if we want to send the info about original OS version each time we are sending the data.

The OS should record this somewhere for debugging purposes. Pinger shouldn't itself need to save this info.

[zonggen]

Yes, if pinger could pick up OS version from /.coreos-aleph-version.json (https://github.com/coreos/coreos-assembler/pull/768) then there's no need for pinger itself to maintain the information.

[zonggen]

For now hardware information will be collected through:

• disk_info: lsblk --fs --json
• cpu_info: lscpu --json
• mem_info: lsmem --json and lsmem --summary
• net_info: sudo cat /var/run/NetworkManager/system-connections/Wired\ connection\ 1.nmconnection, which is the keyfile consumed by NetworkManager:

[core@coreos ~]$ sudo journalctl -u NetworkManager
...
Oct 11 15:38:00 coreos NetworkManager[994]: <info>  [1570808280.9858] keyfile: add connection /var/run/NetworkManager/system-connections/Wired connection 1.nmconnection c2954a02-862d-37a7-b238-58276a8a290c,"Wired connection 1")
...

[jlebon]

net_info: sudo cat /var/run/NetworkManager/system-connections/Wired\ connection\ 1.nmconnection, which is the keyfile consumed by NetworkManager:

Hmm, this seems brittle. Don't have a better suggestion though. @lucab ? Ouhh, nmcli device show looks machine-digestible-ish.

[zonggen]

There's also a Rust crate for NM but it hasn't been updating for a while and cargo fails to pull the dependency from crates.io: (https://crates.io/crates/network-manager).

nmcli device show seems like a better option than cat the keyfile