[openstack-dev] [Ceilometer] Concerning get_resources/get_meters and the Ceilometer API

Doug Hellmann doug.hellmann at dreamhost.com
Fri Aug 16 20:37:41 UTC 2013

On Fri, Aug 16, 2013 at 4:15 PM, Jay Pipes <jaypipes at gmail.com> wrote:

> On 08/16/2013 03:52 PM, Doug Hellmann wrote:
>> However, that's just one example use case. Sometimes people do want to
>> know something about the resources that have existed besides the
>> aggregated samples for billing. The challenge with querying for
>> resources is that the metadata for a given resource has the potential to
>> change over time. The resource table holds the most current metadata,
>> but the meter table has all of the samples and all of the versions of
>> the metadata, so we have to look there to filter on metadata that might
>> change (especially if we're trying to answer questions about what
>> resources had specific characteristics during a time range).
> This is wasteful, IMO. We could change the strategy to say that a resource
> is immutable once it is received by Ceilometer. And if the "metadata" about
> that resource changes somehow (an example of this would be useful) in the
> future, then a new resource record with a unique ID would be generated and
> its ID shoved into the meter table instead of storing a redundant
> denormalized data in the meter.resource_metadata field, which AFAICT, is a
> VARCHAR(1000) field.

To be clear, when I said "resource" I meant something like an instance, not
owned by ceilometer (rather than a row in the resource table).

As Julien pointed out, the existing SQL driver is based on the schema of
the Mongo driver where rather than doing a mapreduce operation every time
we want to find the most current resource data, it is stored separately.
It's quite likely that someone could improve the SQL driver to not require
the resource table at all, as you suggest.


> Anything that can reduce storage space in the base fact table (meter) per
> row will lead to increased performance...
> Best,
> -jay
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130816/262d0451/attachment.html>

More information about the OpenStack-dev mailing list