Repository navigation
Showing VRs in Infrastructure > Virtual Routers fails due to CloudStackVersion.parse(String) #2917
Description
ISSUE TYPE
- Bug Report
COMPONENT NAME
UI
CloudStackVersion
CLOUDSTACK VERSION
master as of Oct 22, 2018
newest commit seems to be #2914
CONFIGURATION
OS / ENVIRONMENT
Installation of the management server is on CentOS 7.5.1804
SUMMARY
Hi,
showing the VRs is not possible in master branch because of the following error:
org.apache.cloudstack.utils.CloudStackVersion.parse(String) passed 0, but requires a value in the format of int.int.int(.int)(-)
We are currently using the following Version-String:
4.12.0.0-1540218507
But it seems it is just not set when trying to access the Virtual Routers in Infrastructure.
STEPS TO REPRODUCE
Open Infrastructure > Virtual Routers
EXPECTED RESULTS
Seeing a list of the vrs.
ACTUAL RESULTS
Seeing error message pictured above.
Activity
yadvr commentedon Oct 22, 2018
Checked, could not reproduce this on 4.11 branch. This seems specific to only master branch.
khos2ow commentedon Oct 23, 2018
@DennisKonrad can you check the VR version directly from the machine?
/etc/cloudstack-release.The weird thing about your screenshot is that it complains
0is not of a correct format in which it should have been4.12.0.0. Basically what the reformatted code does is strip anything after first occurrence of-and process the rest. Which means the value passed toorg.apache.cloudstack.utils.CloudStackVersion.parse()is0-<something>.DennisKonrad commentedon Oct 23, 2018
Hi @khos2ow,
it took me some time to double check on this. It seems there is a problem with the systemvm's we are building at the moment "cloudstack-release" is set to the following for us:
So I think we have to modify something about our SVM-build process so the output of
/etc/cloudstack-releasematches one of the syntaxes in the tests you updated?Thank you very much for this hint
khos2ow commentedon Oct 23, 2018
Yes it should have the same format as in
int.int.int[.int][-branding][-snapshot|timestamp|build_number]DennisKonrad commentedon Oct 23, 2018
@khos2ow your hint led me in the right direction
Many apologies for this. Our jenkins build script had some bug and therefor did not set the version argument for the svm build.sh anymore
But because the error was so misleading we thought there is a bug in your code. Many apologies for this. Thanks for helping
DennisKonrad commentedon Oct 23, 2018
So now
/etc/cloudstack-releaseis back to:This should work fine now. Thank again
DennisKonrad commentedon Oct 23, 2018
One has to really watch out with build.sh to get it right. There's one zero to much. I have to fix it again but then it will be alright
DennisKonrad commentedon Oct 23, 2018
@khos2ow Maybe the version string produced by build.sh without any arguments should also be regarded as a valid version string for a svm so things like that cannot happen?
khos2ow commentedon Oct 23, 2018
No problem at all. There are flags in
build.shwhich you can use to differentiate the incremental builds (I'm AFK now, will check later) but it would be better to produce something like this4.12.0.0-63to prevent confusion. (Use-instead of.)khos2ow commentedon Oct 23, 2018
Yes any thing which conforms to the type of version with additional optinal branding or timestamp (separated by
-) will be regarded as valid.DennisKonrad commentedon Oct 23, 2018
Oh ok, now I fully understand where our problem was coming from.
The build.sh used the BUILD_NUMBER from jenkins without us knowing it and therefor version was set
automatically to the build number in jenkins.
I did not recognize that the magically incrementing number was the same as in jenkins. So this clears it up for me.
Ok, I'm not sure if this automagic link to the jenkins build number is a good thing if it automagically produces systemvm's that will later fail with the error message we got.
Of course it might be a case that happens not so often but if one would like to use the build number he could just call build.sh in jenkins and set the build number as an argument himself.