[
https://issues.apache.org/jira/browse/CLOUDSTACK-9046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15044060#comment-15044060
]
ASF subversion and git services commented on CLOUDSTACK-9046:
-------------------------------------------------------------
Commit 638f1cf091056f518006af46b49bbb9dd7653b92 in cloudstack's branch
refs/heads/master from [~dahn]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=638f1cf ]
Merge pull request #1049 from DaanHoogland/CLOUDSTACK-9047
CLOUDSTACK-9047 rename enumsmake enums adhere to best practice naming
conventions
* pr/1049:
CLOUDSTACK-9046 rename enums to adhere to naming conventions
CLOUDSTACK-9046 renamed enums in kvm plugin
CLOUDSTACK-9047 use 'State's only with context there are more types called
'State' (or to be called so but now 'state') So remove imports and prepend
their enclosing class/context to them.
Signed-off-by: Daan Hoogland <[email protected]>
> 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)
