Task #7761: uncloud v2
[Draft] Define how to handle product modifications
PM Check date:
- 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
- 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
Sample: adding cpu¶
- 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 ram
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.
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
- add disks
- disks need to become a product! at some point.