[Openstack] [ceilometer] Potential New Use Cases

Angus Salkeld asalkeld at redhat.com
Thu Oct 25 22:05:31 UTC 2012


On 25/10/12 17:04 -0400, Doug Hellmann wrote:
>On Thu, Oct 25, 2012 at 10:22 AM, Julien Danjou <julien at danjou.info> wrote:
>
>> On Thu, Oct 25 2012, Doug Hellmann wrote:
>>
>> > That would be one way, but adding "dimensions" to the meters also makes
>> > sense because it reduces the need to collect the data more than once.
>>
>> In case of group, the other problem is how to emit instance counter with
>> group metadata (assuming this group implementation is not part of Nova
>> but Heat).
>>
>
>Good point. I was assuming the values would be available as metadata of the
>underlying resource, but that may not always be the case.
>

Yea, we need a consistent way of doing this. That should work on different
resource types. We could use the tags or a similar mechanism.

-A
>
>>
>> > For instance, if "flavor" was a dimension of the "instance" meter I
>> > wouldn't need the separate meter "instance:<flavor>". These sorts of
>> > use cases were part of the original motivation for collecting all of
>> > the metadata about a resource, but what we have now isn't structured
>> > enough to let the API user query into it.
>>
>> IIUC, what's need here is a GROUP BY operator in the API.
>>
>> Correct me if I'm wrong, but this is still doable via the API if you
>> request /users/<user>/meters/instance and treats the events in the
>> client, no?
>>
>
>It is possible, but very very inefficient.
>
>
>>
>> > How, then, do we define the dimensions for a given meter in a more
>> > structured way? Some built-in values (like flavor) can be pulled
>> > automatically based on the resource type, but what about settings
>> > controlled by the deployer and end-user (for purposes other than
>> billing)?
>>
>> Do we have to define dimensions explicitely, or isn't what's needed just
>> ways to filter and/or group events by metadata fields?
>>
>
>Querying against arbitrary metadata fields is easy in the MongoDB driver,
>but not in the SQLAlchemy driver. Adding explicit handling for dimensions
>would let us implement it in SQL and improve performance with indexes in
>Mongo.
>
>Doug
>
>
>>
>> --
>> Julien Danjou
>> // Free Software hacker & freelance
>> // http://julien.danjou.info
>> g
>>

>_______________________________________________
>Mailing list: https://launchpad.net/~openstack
>Post to     : openstack at lists.launchpad.net
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp





More information about the Openstack mailing list