Open Stack

On Wed, Jan 30 2013, Sandy Walsh wrote:

> Actually ... what if the json payload of the raw event was stored as
> metadata on a Meter?

What do you have in mind: storing the whole payload, or storing
individual fields of the payload? Both looks different to me.

Currently we do store a lot of elements from the payload, but not all,
because we don't have a use case for a lot, like the request_id.

If your need is to store more components from the original payload into
the metadata, that sounds like something possible.

> Is that permitted in Ceilometer?

Yes, it is. You could store that as a string in the key/value of a
metadata.
Usefulness and worthiness of this feature is still discutable.

> If so, this gets us back to a bigger and more interesting question:
>
> If we go with Metadata table + a Meter table we would have to index both
> the Key and Value columns of the Metadata table.
>
> For example:
>
> Some metadata might be:
>
> "event_name" : "compute.instance.run_instance" and
> "request_id" : "xxxx-xxxx-xxxx-xxxx"
>
> And we would want to see all <Foo> meters for request_id = 'xxxx-" and
> event_name = "...."
>
> Having something in Metadata other than primitive data types would
> result in a storage nightmare.

Yes, that's why we ruled it out.

> Which also brings up the point about storing multiple types in the Value
> column under SQL (no-sql is fine). It would have to be a tagged union /
> variant record to say which value is being used:
>
> Metadata
> + key : string
> + data_type : enum
> + integer_value : int
> + float_value : float
> + string_value : string
> + datetime_value : datetime
> + blob_value : memo
> ...
>
> So, I guess we could apply indices only the meaningful data type columns.

Looks like an idea, indeed.

-- 
Julien Danjou
// Free Software hacker & freelance
// http://julien.danjou.info
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130130/4e6c9ae7/attachment.pgp>