Open Stack

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

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

Doug

On Thu, Oct 25, 2012 at 7:11 AM, Julien Danjou <julien at danjou.info> wrote:

> On Thu, Oct 25 2012, Angus Salkeld wrote:
>
> > So we need normal stuff like cpu/mem usage but aggregated over the
> instances
> > in the group. So this is not easy to do externally.
>
> Interesting use case. I think for such a thing, a way would be to have a
> component listening to meters (e.g. on the bus directly or via
> PubSubHubbub-like) to re-emit consolidated meters.
>
> --
> Julien Danjou
> /* Free Software hacker & freelance
>    http://julien.danjou.info */
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20121025/2e92cd05/attachment.html>