Task #7793

Updated by Nico Schottelius over 1 year ago

h2. Draft v1

* Assumption 1: Products are mutable
* Assumption 2: Some products can only be made bigger, not smaller
** f.i. vm disks
* Assumption 3: Orders are immutable
** Once an order is placed, it cannot be changed
** It can be cancelled

Implementation ideas:

* On change we modify the product
* [We might add a log entry (TBD) stating the change (might be too much)]
* In the same transaction we create a new order
* We set new_order.previous_order = old_order
* We set old_order.successor_order = new_order (not sure if both)
* We modify the product to point to the new order
* Obviously all the datetime fields need to be filled in correctly

h2. Sample: adding

* When adding cpus to a VM, the following should happen

* VMProduct changes status to something like "modifying"
* We create / replace orders as described above
* On the vmhost that runs the VM we get a notification (postgres can do that or we poll)
** The VM is stopped (first graceful via acpi with timeout = 1 minute)
** The VM is started with new amount of CPUs

Same flow should be valid for

h2. Sample: removing cpu

* Ensure that cpu count >= 1

* The previous order with recurrence needs still to be billed/paid
** previous order end = next recurring_period / end of period
* Create new order that starts after the end of the previous order with less cpus
* The modification of the VM happens instantly or delayed?
** I think customers would expect instantly

Same flow should be valid for ram.

h2. Removing cpu again before the end of period is reached

* Extending previous case.
* In that case the unstarted newly created order will be cancelled and never billed.
* the 2nd modification will be again the successor order of the cancelled order
** this way we keep history correct

h2. old notes

* cpu
* ram
add disks
** disks need to become a product! at some point.

h2. For now

keep in mind, DON'T SOLVE