We can not get impact estimations of an arbitrary (simulation) or previously created (from-the-past) inventory. Cloud scanner only allows to request impacts of current inventory (live inventory).
Solution
Cloud scanner provides a json inventory format (output) that allow to export an inventory state.
Using the ìnventory` command we could export an inventory (as json) at date-1.
Add a new CLI option like estimate-from-json that could load the saved inventory, and launch it at date-2 (later).
This would allow to assess historical inventory (as it was on date-1) with the data of Boavizta API or other (as it is on date-2).
In the end, it allows easier comparison of results
in time (if Boavizta figures / calculation method) evolve
with different referentials
It would also allow a different use case: simulate the impacts of different variants of inventory / architectures
Alternatives
We could store historical data in cloud scanner, but we prefer not to do it, to keep cloud-scanner as stateless and light as possible.
We consider that the storage / versioning of historical data is not a cloud-scanner concern and should be handled by a specific tool.
Additional context or elements
We should also consider if the inventory capabilities of cloud-scanner should be maintained in a separate module.
Problem
We can not get impact estimations of an arbitrary (simulation) or previously created (from-the-past) inventory. Cloud scanner only allows to request impacts of current inventory (live inventory).
Solution
Cloud scanner provides a json inventory format (output) that allow to export an inventory state.
estimate-from-json
that could load the saved inventory, and launch it at date-2 (later).This would allow to assess historical inventory (as it was on date-1) with the data of Boavizta API or other (as it is on date-2).
In the end, it allows easier comparison of results
It would also allow a different use case: simulate the impacts of different variants of inventory / architectures
Alternatives
We could store historical data in cloud scanner, but we prefer not to do it, to keep cloud-scanner as stateless and light as possible.
We consider that the storage / versioning of historical data is not a cloud-scanner concern and should be handled by a specific tool.
Additional context or elements
We should also consider if the inventory capabilities of cloud-scanner should be maintained in a separate module.