karenetheridge
commented
4 years ago Somewhat related -- should make sure that it's possible to update the hardware assigned to the rack location, and if there already is a device resident in that slot, it should update the device's hardware_product_id as well. Doing so will result in subsequent device reports validating against the new intended hardware type instead of the old hardware.
Right now (in v2.x, and also planned in v3.0), when we receive a device report from livesys, we use the sku that the report provides to determine what type of hardware the device thinks it is, and then we update the device table in the database with that information. Then we execute validations on the report using that (possibly changed) hardware type. The fact that the hardware has changed from what was originally assigned to that rack location is not clearly communicated to the integrator -- it is only apparent in the one single validation "product_name" which compares the hardware product assigned to the rack location to the hardware product (now) associated with the device.
Instead, we should not change the hardware assignment in the device. We should run validations against what we think the hardware should be, and if it is different, that would likely result in a lot of validation failures, making the discrepancy more obvious.
This also prevent circular logic if livesys is querying the api to get configuration information out of the device's hardware product entry, which currently would return configuration for the current device hardware rather than the rack location's assigned hardware.