On Oct 25, 2012, at 6:05 PM, Angus Salkeld <asalk...@redhat.com> wrote:
> 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. 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@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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp