On 25/10/12 17:04 -0400, Doug Hellmann wrote:
On Thu, Oct 25, 2012 at 10:22 AM, Julien Danjou <jul...@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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
