You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cloudstack.apache.org by "Abhinandan Prateek (JIRA)" <ji...@apache.org> on 2013/04/15 14:12:15 UTC

[jira] [Comment Edited] (CLOUDSTACK-1151) vmware systemVm template upgrade is missing in 4.0 upgrade

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

Abhinandan Prateek edited comment on CLOUDSTACK-1151 at 4/15/13 12:11 PM:
--------------------------------------------------------------------------

We donot have upgrade paths between sub-minor versions.

Either we should only check for major and minor versions for db upgrades, we can force this in cloudstack as we do not have any case of db upgrades to/from sub-minor version. 

Or we add the upgrade path to 4.0.2.
                
      was (Author: aprateek):
    We donot have upgrade paths between sub-minor versions, we should only check for major and minor versions for db upgrades. Otherwise we will end up adding many more paths to upgrade scripts.
                  
> vmware systemVm template upgrade is missing in 4.0 upgrade
> ----------------------------------------------------------
>
>                 Key: CLOUDSTACK-1151
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1151
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Template
>    Affects Versions: 4.0.0
>         Environment: vmware esx 4.1/5.1
>            Reporter: Tamas Monos
>            Priority: Blocker
>             Fix For: 4.0.2
>
>
> I have upgraded from 3.0.2 to 4.0.0 and the management server started and updated the database just fine, however the rest of the upgrade procedure just does not work.
> I'm running the script: "nohup cloud-sysvmadm -d 192.168.1.5 -u cloud -p password -c -r > sysvm.log 2>&1 &" accordingly to my environment and see in its log it is trying to stop/start a router.
> It stops it, then recreates the same secondary datastore (vmware) and then starts the same router rather than deploying the new imported systemVM template and creating a new one.
> It neither touches the sec-storage VM nor the console-proxy VM so new management system, old systemVMs.
>  
> No errors during running the script no errors in the log:
> Stopping and starting 1 running routing vm(s)...
> Done restarting router(s).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira