Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

dynamic mapping of device report content -> appropriate database fields #1035

Open
karenetheridge opened this issue Oct 2, 2020 · 0 comments
Labels
device reports Involves data coming from reporters enhancement extends current functionality v3.next features, big changes for api v3.<next>

Comments

@karenetheridge
Copy link
Contributor

karenetheridge commented Oct 2, 2020

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:

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.

@karenetheridge karenetheridge added enhancement extends current functionality device reports Involves data coming from reporters v3.next features, big changes for api v3.<next> labels Oct 2, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
device reports Involves data coming from reporters enhancement extends current functionality v3.next features, big changes for api v3.<next>
Projects
None yet
Development

No branches or pull requests

1 participant