At present (v3.0), when processing a device report, we have hardcoded paths within the report from which to extract the various fields to be added to the database (disks, memory, etc). This will be problematic as we start moving the device report structure around for the validation rewrite (the report structure has to change somewhat in order to accomodate the capabilities and limitations of the JSON Schema format).
We can use the schema information (and therefore device report version) encoded in the Content-Type header to select
from a mapping table the appropriate locations of the various database fields.
For example:
DeviceReport_v3_0_0:
// database table.column -> location in report to extract from
device.system_uuid: /system_uuid
device.uptime_since: /uptime_since
device.hostname: /os/hostname
device.links: /links
relay.serial_number: /relay/serial
device_disk.serial_number: /disks/*
device_disk.slot: /disks/*/slot
...
We will need a mapping table for every new device report format we create. This should be enforced by (what else!) another JSON Schema in order for a new device report format to be eligible for submission by relays.
Builds on #1001.
At present (v3.0), when processing a device report, we have hardcoded paths within the report from which to extract the various fields to be added to the database (disks, memory, etc). This will be problematic as we start moving the device report structure around for the validation rewrite (the report structure has to change somewhat in order to accomodate the capabilities and limitations of the JSON Schema format).
We can use the schema information (and therefore device report version) encoded in the Content-Type header to select from a mapping table the appropriate locations of the various database fields.
For example:
We will need a mapping table for every new device report format we create. This should be enforced by (what else!) another JSON Schema in order for a new device report format to be eligible for submission by relays.