[
https://issues.apache.org/jira/browse/CLOUDSTACK-9046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14996823#comment-14996823
]
ASF GitHub Bot commented on CLOUDSTACK-9046:
--------------------------------------------
Github user borisroman commented on the pull request:
https://github.com/apache/cloudstack/pull/1050#issuecomment-155116207
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 Components
```
> Fix upgrade path from 4.4 and 4.5 to 4.6
> ----------------------------------------
>
> Key: CLOUDSTACK-9046
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9046
> 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 Upgrade442to450.java 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
> fig.py", line 20, in <module> from merge import QueueFile File
> "/opt/cloud/bin/merge.py", line 23, in <module> import cs_ip File
> "/opt/cloud/bin/cs_ip.py", 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
(v6.3.4#6332)
