Different timestamp format for V2 API

[Haili Ma]

I am using V2 API statistics to retrieve metering data from ceilometer. The formats of timestamp in returned data set are different for different meter types. Example: duration_start could be "2013-10-14T01:43:10.988653" or "2013-10-14T01:43:10", which causes timestamp parsing failing. It would be good if the returned data set gives consistent timestamp format.

My code base is in DevStack (RC1) and the content of localrc is attached.
.

Thanks,
hma

CloudCruiser

ADMIN_PASSWORD=qwerty
MYSQL_PASSWORD=qwerty
RABBIT_PASSWORD=qwerty
SERVICE_PASSWORD=qwerty
SERVICE_TOKEN=tokentoken
CINDER_BRANCH=milestone-proposed
GLANCE_BRANCH=milestone-proposed
HORIZON_BRANCH=milestone-proposed
KEYSTONE_BRANCH=milestone-proposed­
NOVA_BRANCH=milestone-proposed
NEUTRON_BRANCH=milestone-proposed
SWIFT_BRANCH=milestone-proposed
CEILOMETER_BRANCH=milestone-proposed
HEAT_BRANCH= milestone-proposed
enable_service ceilometer-acompute ceilometer-acentral ceilometer-collector ceilometer-api
enable_service ceilometer-alarm-notifier ceilometer-alarm-singleton

[Doug Hellmann (doug-hellmann)]

Both of those are valid timestamps. The second example includes fractional seconds.

What are you using to parse the values?

[Haili Ma (hailim)]

Yes, both of them are valid, but, they are in different formats.
I use "yyyy-MM-dd'T'HH:mm:ss" to parse the short one, but it fails on
the longer one. If I use "yyyy-MM-dd'T'HH:mm:ss.SSSSSS" to parse the
longer one, it does not work for the first one so that I need to convert
one to another. Do you have recommended solution or can you return the
timestamp in one format?

We use some Java package to parse it:

org.joda.time.format
DateTimeFormatter

Thanks,
Haili

On Tue, 2013-10-15 at 18:31 +0000, Doug Hellmann wrote:
> Both of those are valid timestamps. The second example includes
> fractional seconds.
>
> What are you using to parse the values?
>

[Doug Hellmann (doug-hellmann)]

OK, I don't know about parsing timestamps in Java. If you don't care about the extra data, you could strip off the trailing .SSSSS, I guess.

Are the timestamps different for the same meter name?

[Haili Ma (hailim)]

For the same meter name, the format for the duration_start is same.

What is reason for you to use different timestamp formats for the same
type of data like duration_start?

On Tue, 2013-10-15 at 20:51 +0000, Doug Hellmann wrote:
> OK, I don't know about parsing timestamps in Java. If you don't care
> about the extra data, you could strip off the trailing .SSSSS, I guess.
>
> Are the timestamps different for the same meter name?
>

[Doug Hellmann (doug-hellmann)]

The data values are coming from different places, and are being sent with different amounts of precision apparently.

Can you help out by providing a list of meters for each format? That would help narrow down the source of the issue.

[Thomas Maddox (thomas-maddox)]

Which backend is being used? Was ceilometer.conf edited at all? Up until 2 years ago, MySQL had precision issues with temporal column types, so we would potentially see different precisions with anything that hasn't been converted to using the custom PreciseTimestamp column type or Decimal and a conversion to a DateTime object at the storage driver.

[Thomas Maddox (thomas-maddox)]

Specifically MySQL 5.6.4: http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-4.html

[Haili Ma (hailim)]

I do have a complete list and here is what I got for meters with longer
timestamp:

meter name = disk.root.size
meter name = volume.size
meter name = image.delete
meter name = vcpus
meter name = image.download
meter name = image.update
meter name = instance:m1.tiny
meter name = instance
meter name = image.size
meter name = image.upload
meter name = image
meter name = memory
meter name = instance:m1.nano
meter name = image.serve
meter name = volume
meter name = disk.ephemeral.size

On Tue, 2013-10-15 at 22:03 +0000, Doug Hellmann wrote:
> The data values are coming from different places, and are being sent
> with different amounts of precision apparently.
>
> Can you help out by providing a list of meters for each format? That
> would help narrow down the source of the issue.
>

[Haili Ma (hailim)]

Sorry, I do not have complete list

[Haili Ma (hailim)]

I did not edit ceilometer.conf, what do you mean by "which backend"?

[Doug Hellmann (doug-hellmann)]

I think Thomas means which database are you using?

[Thomas Maddox (thomas-maddox)]

Sorry. Ceilometer can use several storage backends:

1. SQLAlchemy (should support MySQL and PostgreSQL)
2. MongoDB
3. HBase
4. DB2 (NoSQL)

If you did not edit ceilometer.conf, and 'CEILOMETER_BACKEND' is not set somewhere in your local settings, then you're using the default for DevStack, which should be MySQL: https://github.com/openstack-dev/devstack/blob/master/lib/ceilometer#L94-L95

I was just trying to narrow down the culprits.

To clarify, your list of meters above are the ones that are showing the sub-second timestamp, e.g. "2013-10-14T01:43:10.988653"?

Thanks!

[Haili Ma (hailim)]

I am using MySQL which is default installation for DevStack.

Yes, the list of meters show the timestamp format like
"2013-10-14T01:43:10.988653" for for tag duration_start

On Wed, 2013-10-16 at 16:53 +0000, Thomas Maddox wrote:
> Sorry. Ceilometer can use several storage backends:
>
> 1. SQLAlchemy (should support MySQL and PostgreSQL)
> 2. MongoDB
> 3. HBase
> 4. DB2 (NoSQL)
>
> If you did not edit ceilometer.conf, and 'CEILOMETER_BACKEND' is not set
> somewhere in your local settings, then you're using the default for
> DevStack, which should be MySQL: https://github.com/openstack-
> dev/devstack/blob/master/lib/ceilometer#L94-L95
>
> I was just trying to narrow down the culprits.
>
> To clarify, your list of meters above are the ones that are showing the
> sub-second timestamp, e.g. "2013-10-14T01:43:10.988653"?
>
> Thanks!
>

[Haili Ma (hailim)]

Here is results from info.sh on my local machine:

./info.sh
os|distro=precise
os|vendor=Ubuntu
os|release=12.04
git|ceilometer|milestone-proposed[ec31468]
git|cinder|milestone-proposed[2d8ad0d]
git|glance|milestone-proposed[42cfa8c]
git|horizon|milestone-proposed[d716bfc]
git|keystone|master[b426fa5]
git|nova|milestone-proposed[3c373ac]
git|noVNC|master[142aa45]
git|oslo.config|master[1a846bf]
git|oslo.messaging|master[91f74d8]
git|pbr|master[ae25b56]
git|python-ceilometerclient|master[c3283ec]
git|python-cinderclient|master[873bed9]
git|python-glanceclient|master[cd11833]
git|python-heatclient|master[ecec0b1]
git|python-keystoneclient|master[cc0e06f]
git|python-neutronclient|master[1dd88b9]
git|python-novaclient|master[a5c8d21]
git|python-openstackclient|master[29642c2]
git|python-swiftclient|master[1aa8596]
git|requirements|master[f064bf2]
git|tempest|master[f55f4e5]
pkg|bridge-utils|1.5-2ubuntu7
pkg|pylint|0.25.0-1ubuntu1
pkg|python-setuptools|0.6.24-1ubuntu1
pkg|screen|4.0.3-14ubuntu8
pkg|unzip|6.0-4ubuntu1
pkg|wget|1.13.4-2ubuntu1
pkg|psmisc|22.15-2ubuntu1.1
pkg|git|1:1.7.9.5-1
pkg|lsof|4.81.dfsg.1-1build1
pkg|openssh-server|1:5.9p1-5ubuntu1.1
pkg|openssl|1.0.1-4ubuntu5.10
pkg|vim-nox|2:7.3.429-2ubuntu2.1
pkg|locate|4.4.2-4ubuntu1
pkg|python-virtualenv|1.7.1.2-1
pkg|python-unittest2|0.5.1-1ubuntu1
pkg|iputils-ping|3:20101006-1ubuntu1
pkg|wget|1.13.4-2ubuntu1
pkg|curl|7.22.0-3ubuntu4.3
pkg|tcpdump|4.2.1-1ubuntu2
pkg|euca2ools|2.0.0~bzr516-0ubuntu3.1
pkg|tar|1.26-4ubuntu1
pkg|python-cmd2|0.6.3-1
pkg|gcc|4:4.6.3-1ubuntu5
pkg|libxml2-dev|2.7.8.dfsg-5.1ubuntu4.6
pkg|python-dev|2.7.3-0ubuntu2.2
pkg|python-eventlet|0.9.16-1ubuntu4.2
pkg|python-routes|1.12.3-1ubuntu1
pkg|python-greenlet|0.3.1-1ubuntu5.1
pkg|python-sqlalchemy|0.7.4-1ubuntu0.1
pkg|python-wsgiref|
pkg|python-pastedeploy|1.5.0-2build1
pkg|python-xattr|0.6.2-1ubuntu1
pkg|python-iso8601|0.1.4-1ubuntu1
pkg|python-dev|2.7.3-0ubuntu2.2
pkg|python-lxml|2.3.2-1
pkg|python-pastescript|1.7.5-1
pkg|python-pastedeploy|1.5.0-2build1
pkg|python-paste|1.7.5.1-4ubuntu2
pkg|sqlite3|3.7.9-2ubuntu1.1
pkg|python-pysqlite2|2.6.3-2build1
pkg|python-sqlalchemy|0.7.4-1ubuntu0.1
pkg|python-mysqldb|1.2.3-1ubuntu0.1
pkg|python-webob|1.1.1-1ubuntu0
pkg|python-greenlet|0.3.1-1ubuntu5.1
pkg|python-routes|1.12.3-1ubuntu1
pkg|libldap2-dev|2.4.28-1.1ubuntu4.4
pkg|libsasl2-dev|2.1.25.dfsg1-3ubuntu0.1
pkg|python-dateutil|1.5-1
pkg|msgpack-python|0.1.10-1
pkg|dnsmasq-base|2.59-4ubuntu0.1
pkg|dnsmasq-utils|2.59-4ubuntu0.1
pkg|kpartx|0.4.9-3ubuntu5
pkg|parted|2.3-8ubuntu5.1
pkg|iputils-arping|3:20101006-1ubuntu1
pkg|python-mysqldb|1.2.3-1ubuntu0.1
pkg|python-xattr|0.6.2-1ubuntu1
pkg|python-lxml|2.3.2-1
pkg|gawk|1:3.1.8+dfsg-0.1ubuntu1
pkg|iptables|1.4.12-1ubuntu5
pkg|ebtables|2.0.9.2-2ubuntu2
pkg|sqlite3|3.7.9-2ubuntu1.1
pkg|sudo|1.8.3p1-1ubuntu3.4
pkg|libjs-jquery-tablesorter|4-1
pkg|vlan|1.9-3ubuntu6
pkg|curl|7.22.0-3ubuntu4.3
pkg|genisoimage|9:1.1.11-2ubuntu2
pkg|socat|1.7.1.3-1.2
pkg|python-mox|0.5.3-1ubuntu5
pkg|python-paste|1.7.5.1-4ubuntu2
pkg|python-migrate|0.7.2-1ubuntu1
pkg|python-gflags|1.5.1-1build1
pkg|python-greenlet|0.3.1-1ubuntu5.1
pkg|python-libxml2|2.7.8.dfsg-5.1ubuntu4.6
pkg|python-routes|1.12.3-1u...

[Thomas Maddox (thomas-maddox)]

Great thanks! Looking into it further.

[Thomas Maddox (thomas-maddox)]

Python's DateTime object automatically returns without sub-second in the string if microsecond is 0, and WSME appears to just default to the same behavior. It's a DateTime object still at the API controller.

Debug output:

With __repr__():
2013-10-16 17:59:30.292 14800 DEBUG ceilometer.api.controllers.v2 [-]

durations: [datetime.datetime(2013, 10, 16, 17, 10, 39), datetime.datetime(2013, 10, 16, 17, 40, 38)] _update_duration

/opt/stack/ceilometer/ceilometer/api/controllers/v2.py:676

With __str__():
2013-10-16 18:00:55.994 14927 DEBUG ceilometer.api.controllers.v2 [-]

durations: ['2013-10-16 17:10:39', '2013-10-16 18:00:38'] _update_duration

/opt/stack/ceilometer/ceilometer/api/controllers/v2.py:676

[Thomas Maddox (thomas-maddox)]

I would like to make this consistent for UX, though it is still ISO8601 compliant.

Does Java have a compliant parser? I couldn't find anything poking around some standard date libraries for Java.

[Thomas Maddox (thomas-maddox)]

Is this helpful? http://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html

[Haili Ma (hailim)]

It's helpful and thanks! we use the pattern "yyyy-MM-dd'T'HH:mm:ss" to
parse the timestamp. I guess that we are good as long as the timestamp
format is consistent.

On Wed, 2013-10-16 at 19:24 +0000, Thomas Maddox wrote:
> Is this helpful?
> http://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html
>