openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

On Oct 25, 2012, at 6:05 PM, Angus Salkeld <asalkeld@xxxxxxxxxx> wrote:

> On 25/10/12 17:04 -0400, Doug Hellmann wrote:
>> On Thu, Oct 25, 2012 at 10:22 AM, Julien Danjou <julien@xxxxxxxxxxx> 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.

Tags would be available as part of an objects normal metadata, right?

Doug

> 
> -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@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp