cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-9046) Fix upgrade path from 4.4 and 4.5 to 4.6
Date Mon, 09 Nov 2015 16:35:11 GMT


ASF GitHub Bot commented on CLOUDSTACK-9046:

Github user borisroman commented on the pull request:
    LGTM :+1: 
    Deployed 4.5.2 from DEB packages on Ubuntu 14.04. Deployed a zone, deployed the systemvm's
and spawned a uservm.
    Upgraded to 4.6 with packages build from this branch. Upgrade went ok! :+1: 
    INFO  [c.c.u.DatabaseUpgradeChecker] (main:null) DB version = 4.5.2 Code Version = 4.6.0
    INFO  [c.c.u.DatabaseUpgradeChecker] (main:null) Database upgrade must be performed from
4.5.2 to 4.6.0
    INFO  [c.c.u.DatabaseUpgradeChecker] (main:null) Cleaning upgrades because all management
server are now at the same version
    INFO  [c.c.u.DatabaseUpgradeChecker] (main:null) Cleanup upgrade Upgrade452to460 to upgrade
from 4.5.2-4.6.0 to 4.6.0
    INFO  [o.a.c.s.l.CloudStackExtendedLifeCycle] (main:null) Configuring CloudStack Components
    INFO  [o.a.c.s.l.CloudStackExtendedLifeCycle] (main:null) Done Configuring CloudStack

> Fix upgrade path from 4.4 and 4.5 to 4.6
> ----------------------------------------
>                 Key: CLOUDSTACK-9046
>                 URL:
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Upgrade
>    Affects Versions: 4.6.0
>            Reporter: Wilder Rodrigues
>            Assignee: Wilder Rodrigues
>            Priority: Blocker
>             Fix For: 4.6.0
> When upgrading to 4.6 from 4.5 or earlier, the systemvm template that is registered upfront
is not marked as SYSTEM and set as the template for the existing systemvms. Therefore, new
systemvms work fine but existing ones don't.
> RCA is missing code in the upgrade path, as is present when upgrading from 4.4 to 4.5
for example.
> The code in the is not generic, as the name suggests, and simply
configures the whole SystemVM and all the existing Domain VMs to use the SystemVM-4.5.0 that
was registered. It means that after the upgrade all the routers were marked okay, but they
were using the old stuff, from 4.5.0. The attempt to deploy a new VM was also failing with
the following error (on the host):
> 2015-11-07 18:17:31,135 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-4:null)
Exit value is 1
> 2015-11-07 18:17:31,135 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-4:null)
Traceback (most recent call last):  File "/opt/cloud/bin/update_con
>", line 20, in <module>    from merge import QueueFile  File "/opt/cloud/bin/",
line 23, in <module>    import cs_ip  File "/opt/cloud/bin/", lin
> e 19, in <module>    from netaddr import *ImportError: No module named netaddr
> Why that? Because the KVM host has the new systemvm.iso, which contains all the new python
stuff, but the systemvm template, which installs the Guest OS (Debian) is old and does not
contain the modules we now need.

This message was sent by Atlassian JIRA

View raw message