[openstack-dev] [Ceilometer] Concerning get_resources/get_meters and the Ceilometer API
jaypipes at gmail.com
Sun Aug 18 19:04:22 UTC 2013
On 08/17/2013 03:10 AM, Julien Danjou wrote:
> On Fri, Aug 16 2013, Jay Pipes wrote:
>> Actually, that's the opposite of what I'm suggesting :) I'm suggesting
>> getting rid of the resource_metadata column in the meter table and using the
>> resource table in joins...
> I think there's a lot of scenario where this would fail, like for
> example instances being resized; the flavor is a metadata.
I'm proposing that in these cases, a *new* resource would be added to
the resource table (and its ID inserted in meter) table with the new
> Though, changing the schema to improve performance is a good one, this
> needs to be thought from the sample sending to the storage, through the
> whole chain. This is something that will break a lot of current
> assumption; that doesn't mean it's bad or we can't do it, just that we
> need to think it through. :)
Yup, understood completely. The change I am proposing would not affect
any assumptions made from the point of view of a sample sent to storage.
The current assumption is that a sample's *exact* state at time of
sampling would be stored so that the exact sample state could be
reflected even if the underlying resource that triggered the sample
changed over time.
All I am proposing is a change to the existing implementation of that
assumption: instead of storing the original resource metadata in the
meter table, we instead ensure that we store the resource in the
resource table, and upon new sample records being inserted into the
meter table, we check to see if the resource for the sample is the same
as it was last time. If it is, we simply insert the resource ID from
last time. If it isn't, we add a new record to the resource table that
describes the new resource attributes, and we insert that new resource
ID into the meter table for that sample...
More information about the OpenStack-dev