| Summary: | if the OS version has only major version, the REST logs an exception | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Tomas Jelinek <tjelinek> |
| Component: | RestAPI | Assignee: | Juan Hernández <juan.hernandez> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Petr Matyáš <pmatyas> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 3.6.3 | CC: | bugs, mgoldboi, oourfali |
| Target Milestone: | ovirt-3.6.4 | Flags: | rule-engine:
ovirt-3.6.z+
mgoldboi: planning_ack+ juan.hernandez: devel_ack+ pstehlik: testing_ack+ |
| Target Release: | 3.6.4 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-04-05 13:54:06 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Infra | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
This is very similar to bug 1311616, which will be fixed in 3.6.4. However the solution includes sending a warning to the log, something like this: ---8<--- The version string "23" doesn't match the expected pattern, only the full version will be reported. --->8--- Maybe we should make that a debug message instead of a warning. Well, actually a number like "23" won't produce the warning, but other things like "v23" will. I think we can close this bug open, just to verify that. Verified on 3.6.4-1 |
If the OS version reported by guest agent does not contain a minor version, the /api/vms prints a stack trace to the logs containing: 2016-03-15 10:03:42,945 ERROR [org.ovirt.engine.api.restapi.types.VersionMapper] (ajp-/127.0.0.1:8702-104) [] Failed to map version string minor component: java.lang.NumberFormatException: For input string: "" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.7.0_95] at java.lang.Integer.parseInt(Integer.java:504) [rt.jar:1.7.0_95] at java.lang.Integer.parseInt(Integer.java:527) [rt.jar:1.7.0_95] at org.ovirt.engine.api.restapi.types.VersionMapper.fromVersionString(VersionMapper.java:82) [restapi-types.jar:] at org.ovirt.engine.api.restapi.types.VmMapper.map(VmMapper.java:457) [restapi-types.jar:] at org.ovirt.engine.api.restapi.types.VmMapper.map(VmMapper.java:330) [restapi-types.jar:] at sun.reflect.GeneratedMethodAccessor274.invoke(Unknown Source) [:1.7.0_95] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_95] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_95] at org.ovirt.engine.api.restapi.types.MappingLocator$MethodInvokerMapper.map(MappingLocator.java:150) [restapi-types.jar:] The problem is that all the Fedora have only major versions (e.g. 23). If you have lots of VMs in the system like this, the log is than full of this stack traces. It is not a functional mistake since the returned version is correct (e.g. <version major="23" full_version="23"/>" but if you have couple of hundreds of VMs like this, the log becomes unreadable.