New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Timestamps are incorrectly parsed in Ceilometer statistics #928
Comments
AFAIK, the parser is expecting milliseconds after 'dot'. But in this response (this is common for openstack and python) 426000 are microseconds. Probably another DateFormat can be written and used as default to parse dates. Or jackson-databind can be fixed to address this issue. |
Since you already digged in to the details, would you like to submit a fix @ZsergUA? |
Hey guys, I created a PR to address this fix, could someone check it out? Thanks |
… sample-criteria-limit # By Patrick Dube (8) and others # Via GitHub (4) and Renat Akhmerov (1) * 'master' of https://github.com/ContainX/openstack4j: Mistral: add cron trigger endpoint Mistral: add workflow environment endpoint Added a couple tests Collapsed if statement Using a StdDeserializer instead of processing it in the class. Reverting changes to groupby. Fixed decimals for period as well Modifying spacing Adding groupby field to Statistics Reverted change for period Mistral: add action execution endpoint Mistral: add task execution endpoint added display_name and display_description properties to maintain backwards compatibility with deprecated v1 API git ignore intelliJ generated project files ContainX#928 Ignoring microseconds in Date processing Renamed CinderVolume properties to be compatible with block storage API v2, fixed broken VolumeTests Conflicts: core/src/main/java/org/openstack4j/model/telemetry/SampleCriteria.java core/src/main/java/org/openstack4j/openstack/telemetry/internal/MeterServiceImpl.java
… dist-management # By Patrick Dube (10) and others # Via GitHub (4) and others * 'master' of https://github.com/ContainX/openstack4j: Set the old deprecated fields in the builder to support cinder API v1 and set in the serialized json request during volume creation Fixed tests Added tests Mistral: add cron trigger endpoint Mistral: add workflow environment endpoint Added a couple tests Collapsed if statement Using a StdDeserializer instead of processing it in the class. Reverting changes to groupby. Fixed decimals for period as well Modifying spacing Adding groupby field to Statistics Reverted change for period ContainX#928 Ignoring microseconds in Date processing
FYI this issue affects authentication as well (seen in 3.0.3). When combined with an Openstack service that always zeros the sub-second part of the issued_at (my server told me "issued_at": "2017-08-30T12:46:51.000000Z" in this case) this results in the expected login duration being 8 minutes (480655ms ~= 8 minutes) longer than the server permitted, meaning that my code (the Jenkins openstack-cloud plugin) trying use the token past its expiry time. I think what's needed is some form of intelligent parsing so we treat the first digit in the sub-second field (if present) as hundreds of milliseconds, the second digit as tens of milliseconds, the third as milliseconds and ignore any extra. i.e. just read it to millisecond precision regardless of the precision it was given in. |
This specific issues and the attached PR refers to ceilometer endpoint specifically. With @pjdarton, we observe that on Keystone tokens. Should it be tracked separately or will the work continue here? |
Looks like it is fixed in new jackson starting from 2.9.0 version |
Running openstack4j 3.0.3 I see some weird parsing behavior when query results from Ceilometer are being deserialized.
The following code:
yields the following result (with request logging turned on):
As can be seen, the
periodStart
andperiodEnd
fields in the returnedCeilometerStatistics
objects are incorrect when we compare them to theperiod_start
andperiod_end
fields in the raw JSON response. For example,periodStart
should beFri Jan 27 13:35:55 CET 2017
in the first case but isFri Jan 27 13:43:01 CET 2017
.I haven't been able to dig into the exact cause of the problem, but I've managed to find out that it is likely due to using
Parser.asDate
to parse these timestamps, since running:results in
Fri Jan 27 13:43:01 CET 2017
.The text was updated successfully, but these errors were encountered: