Hi all, Thanks for creating this release candidate Rajani.
I’ve run some upgrade tests and have some results to share with you all. Hopefully we could address them. 4.5 -> 4.10 Following the upgrade instructions from this page: http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.10/upgrade/upgrade-4.5.html I’ve registered the template with the right naming: "systemvm-kvm-4.10”, waited until it was in Ready status. Then following the upgrade procedure, upgraded the management and the cs-agent. Upon starting the management the db.upgrade kicked in, but it failed with the following error: com.cloud.utils.exception.CloudRuntimeException: 4.6.0KVM SystemVm template not found. Cannot upgrade system Vms It appears that the upgrade script is still looking for 4.6 ssvm template while a newer version is installed. Created an issue: https://issues.apache.org/jira/browse/CLOUDSTACK-9807 4.9 -> 4.10 Following the same source of information (http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.10/upgrade/upgrade-4.9.html) I’ve registered the template with the right naming: "systemvm-kvm-4.10”, waited until it was in Ready status. Then upgraded management and the cloudstack-agent on all hosts. Upon starting the management, the DB upgrade was successful. I’ve logged in the system and observed that it was still using 4.6.0 ssvm templates. The option to upgrade the VR wasn’t available as well. Checking global settings it turns out minreq.sysvmtemplate.version = 4.6.0 and router.template.kvm was pointing to the original ssmv template (not systemvm-kvm-4.10). The original ssvm template is still in active state but it should be in InActive. This basically leaves the user unable to upgrade ssvm (which are not working btw) without hacking the DB and global settings Created an issue: https://issues.apache.org/jira/browse/CLOUDSTACK-9808 I think these two issues should be addressed in the db upgrade script. Also it is worth mentioning that when you get to the point where you can see the upgrade button on the VR, when clicking on it, it doesn’t do anything but restarting. In order to actually upgrade the router you’ll need to do a network restart (with cleanup option), which will recreate the router. There are also smoketests running on fresh installations of 4.10. I’m expecting the results to come up soon, I’ll keep you posted. Thanks, Boris Stoyanov boris.stoya...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue On Mar 1, 2017, at 9:21 AM, Wido den Hollander <w...@widodh.nl<mailto:w...@widodh.nl>> wrote: Op 1 maart 2017 om 2:12 schreef Rajani Karuturi <raj...@apache.org<mailto:raj...@apache.org>>: Hi All, I've created a 4.10.0.0 release, with the following artifacts up for a vote: Git Branch and Commit SH:https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.10.0.0-RC20170301T0634 Commit:7c1d003b5269b375d87f4f6cfff8a144f0608b67 <https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.10.0.0-RC20170301T0634Commit:7c1d003b5269b375d87f4f6cfff8a144f0608b67> Source release (checksums and signatures are available at the same location):https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/ I get a 404 here. Am I too early to fetch the tarball? I always prefer to test with a tarball instead of a Git repo. Trying to prevent I accidentally test with a wrong commit/branch. Wido PGP release keys (signed using CBB44821):https://dist.apache.org/repos/dist/release/cloudstack/KEYS Vote will be open for 72 hours. For sanity in tallying the vote, can PMC members please be sure to indicate "(binding)" with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) ~Rajani http://cloudplatform.accelerite.com/
