openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

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.


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