inconsistent use of metadata and resource_metadata in /v2/meters API

[Eoghan Glynn]

It seems a tad asymmetric that the "resource_" prefix must be dropped from a samples query that contrains the metadata, e.g.

  GET /v2/meters/network.incoming.bytes?q.op=eq&q.value=UUID&q.field=metadata.instance_id

as opposed to:

  GET /v2/meters/network.incoming.bytes?q.op=eq&q.value=UUID&q.field=resource_metadata.instance_id

whereas we encode the actual samples returned with "resource_metadata" instead of "metadata", e.g.:

   {"counter_name": "network.incoming.bytes", "resource_metadata": {"instance_id": "UUID" ...} ...}

Seems the "resource_" prefix used within the metering store is leaking into the API in an inconsistent way.

We should consistently use "metadata" are both query constraints and the samples representation returned.

[Eoghan Glynn (eglynn)]

@xingzhou: FYI I had a patch prepared for this bug implementing s/Sample.resource_metadata/Sample.metadata/ but I've concerns about API stability.

Seems a better approach might be to allow both resource_metedata and metadata in the query parameters, i.e:

  GET /v2/meters/network.incoming.bytes?q.op=eq&q.value=UUID&q.field=metadata.instance_id

and:

  GET /v2/meters/network.incoming.bytes?q.op=eq&q.value=UUID&q.field=reasource_metadata.instance_id

to be considered equivalent.

This would allow existing v2 API callers to remain unaffected.

What do you think?

[xingzhou (xingzhou)]

@Eoghan, I think that's ok, and then it means only the returned json shall be changed to only use metadata, am I correct?

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/43310
Committed: http://github.com/openstack/ceilometer/commit/502824ad2c0a0af0d51be9d600f390dbcd3918eb
Submitter: Jenkins
Branch: master

commit 502824ad2c0a0af0d51be9d600f390dbcd3918eb
Author: Julien Danjou <email address hidden>
Date: Thu Aug 22 18:33:50 2013 +0200

    api: allow usage of resource_metadata in query

    When returning samples, they have a field called resource_metadata, and
    therefore it may seem nature to filter on it using this as a prefix in
    queries. Let's allow use of it.

    Fixes-Bug: #1195765

    Change-Id: I82f591e0d38a3063a9762de1ac64dc3ef9d29ee7