Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

-          make it part of the service offering; like local storage. Admin has to configure it, but user gets the option of choosing it (Community choice) i.e. the admin (Operator) will first have to make this an option of the service (compute) offering if he want to provide this. Then the end-user gets to choose if he wants it or not

...

Open Questions:

...

- how long will the template be stored in primary if the deployments of a VM in a cluster are all non-linked clones? Any optimization can be done here, in terms of deletion and retrival?

- If the ability to request a linked vs. non-linked clone is tied to a service (compute) offering, how do we deal with different hypervisor capabilities? i.e. if KVM or OVM dont support this, but the user selects linked clone option - do we just "silently" ignore this?

- If a VM is created as a linked clone, there is no need to make it non-linked clone afterwards (or vice-versa)

- similarly, if upgrading from 4.0 to 4.1, VMs created in 4.0 (linked clones) dont need to be allowed to become non-linked clones

- to keep it simple, alternatively, the ability to use linked clones or full-clones could be a global setting, with a default value of full clone

Upgrade issues

-          Existing VMs will not be impacted

-          New VMs deployed will be full clone (assuming full clone is the global option chosen)

Similarly, changing the global setting from one to another (must be discouraged!!!), but as above, existing VMs will not be impacted, only new VMs will be deployed as per the global setting at the time of deployment- after introduction of this capability, for usage/billing purposes, there must be a mechanism to inform that a VM is using linked vs. non-linked clones (premium service will provide non-linked clones and charge extra, for example)