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

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

GitHub user nvazquez opened a pull request:

    https://github.com/apache/cloudstack/pull/1727

    CLOUDSTACK-9539: Support changing Service offering for instance with VM 
Snapshots

    ## Actual behaviour
    CloudStack doesn't support changing service offering for vm instances which 
have vm snapshots, they should be removed before changing service offering.
    
    ## 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.
    
    ## 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.
    
    ## 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

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/nvazquez/cloudstack change-serv-offering

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/cloudstack/pull/1727.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #1727
    
----
commit c7d51461250d5585a61cf8d12bf28a8380125d0a
Author: nvazquez <nicolas.m.vazq...@gmail.com>
Date:   2016-10-14T15:23:38Z

    CLOUDSTACK-9539: Support changing Service offering for instance with VM 
Snapshots

----


> 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