[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15604460#comment-15604460
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9539:
--------------------------------------------

Github user koushik-das commented on a diff in the pull request:

    https://github.com/apache/cloudstack/pull/1727#discussion_r84839190
  
    --- Diff: core/src/com/cloud/agent/api/VMSnapshotTO.java ---
    @@ -35,6 +35,7 @@
         private VMSnapshotTO parent;
         private List<VolumeObjectTO> volumes;
         private boolean quiescevm;
    +    private Long serviceOfferingId;
    --- End diff --
    
    Don't see any use of service offering stored here, is it needed? *TO 
objects are used to pass data from orchestration layer to agent layer.


> Support changing Service offering for instance with VM Snapshots
> ----------------------------------------------------------------
>
>                 Key: CLOUDSTACK-9539
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the 
> default.) 
>            Reporter: Nicolas Vazquez
>            Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to