Project

General

Profile

Actions

Task #7793

open

Task #7761: uncloud v2

[Draft] Define how to handle product modifications

Added by Nico Schottelius almost 2 years ago. Updated 10 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
02/28/2020
Due date:
% Done:

0%

Estimated time:
PM Check date:

Description

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

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

old notes

  • cpu
  • ram
  • add disks
    • disks need to become a product! at some point.
Actions #1

Updated by Nico Schottelius almost 2 years ago

  • Description updated (diff)
Actions #3

Updated by Nico Schottelius over 1 year ago

  • Description updated (diff)
  • Subject changed from queue: allow VMs to be modified to [Draft] Define how to handle product modifications
Actions #4

Updated by Timothée Floure 10 months ago

  • Assignee deleted (Timothée Floure)
Actions

Also available in: Atom PDF