I have just upgraded my OpenNebula from 4.14.2 to 5.0.2 (including onedb fsck, and so on). Now I can see my hosts, users. vnets and datastores in Sunstone, but there are no VMs, templates, images or files. Neither in the dashboard, nor in the tabs like “Instances”, etc. In the Sunstone dashboard, there is not even the number “0” for running VMs - the numbers are completely missing: the VMs section header reads: “VMs ACTIVE PENDING FAILED”.
The command-line tools can see the VMs correcty: onevm list, onetemplate list, oneimage list, etc. all return the data about preexisting VMs, templates, images, etc.
The hosts in my cluster are all visible in Sunstone and have the status “ON” (and some of them DISABLED, as they were before the upgrade).
I am not aware of doing anything strange during the upgrade. There were two “nonstandard” things during the upgrade:
questions from “onedb upgrade”, which asked about the VLAN attribute for all my VNETs:
Net #5 (sit43) has VN_MAD='ebtables' but it also has VLAN=NO. Change to 'fw'? (y/n)
(I answered “no” for all my VNETs).
The onehost sync command reported that it failed to update about 10 out of 27 hosts, but after a minute or so, another onehost sync reported that there were no hosts to update.
InvalidCharacterError: String contains an invalid character main.js?v=5.0.2 (line 81666)
InvalidCharacterError: String contains an invalid character main.js?v=5.0.2 (line 102124)
"NetworkError: 401 Unauthorized - https://my.sunstone.host/support/request?timeout=false&csrftoken=...5040482" request...5040482
Also, I have discovered that when I log in as an ordinary user instead of oneadmin, I can see only the grey box on the left (“OpenNebula 5.0.2 by OpenNebula Systems”), and an animated spinner in the middle. The error messages are the following:
unreachable code after return statement main.js:69875:16
mutating the [[Prototype]] of an object will cause your code to run very slowly; instead create the object with the correct initial [[Prototype]] value using Object.create main.js:124410:19794
Error: No tabs/oneflow-dashboard-tab
FWIW, my hosts are CentOS 7 and OpenNebula packages were installed from the tarball for RHEL7/CentOS7 linked from http://opennebula.org/software/.
I guess I am doing something very stupid somewhere :-), but I cannot figure out what it is.
thanks for the quick fix, I will look at it. However: you seem to abuse the “release:” tag in the RPM packages: the RPM package name consists of the following parts: name-version-release.arch.rpm: the name is, of course, opennebula (or opennebula-whatever). The version part should be the “upstream” source code version, from which the RPM packages are created. Should the upstream source change, the version should be changed as well. The name-version should refer to a particular source code tarball. The release part should refer solely to the packaging modifications of the same source code tarball. I.e. the features specific to the RPM (or DEB) packaging, such asi init scripts, %post scripts, or whatever.
Today, you have apparently upgraded opennebula-whatever-5.0.2-1.arch.rpm to opennebula-whatever-5.0.2-2.arch.rpm. This suggests only the parts specific to RPM packaging were changed, and nothing else. Definitely not the “upstream” source code. However, running diff -u ${name%.rpmsave} ${name} on my computer reveals that significant upstream changes has been made, for example:
This is definitely not a modification specific to the RPM packaging, This is an upstream source code modification, which should result in the “version:” tag increment. Please be bold enough to call it 5.0.3 or whatever, and do not try to hide behind the RPM packaging release number.
In order to keep my local modifications to the OpenNebula configuration files manageable I would kindly like to ask you to bump the “version” part up every time the “upstream” sources are modified, and keep the “release” number increments solely for modifications related to RPM (or DEB) packaging.