Open Stack

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).

> 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?

> 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?

-- 
Julien Danjou
// Free Software hacker & freelance
// http://julien.danjou.info
g
-------------- 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/attachments/20121025/3eabaaee/attachment.sig>