inconsistent use of metadata and resource_metadata in /v2/meters API
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ceilometer |
Fix Released
|
Low
|
Julien Danjou |
Bug Description
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/
as opposed to:
GET /v2/meters/
whereas we encode the actual samples returned with "resource_metadata" instead of "metadata", e.g.:
{"counter_name": "network.
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.
description: | updated |
Changed in ceilometer: | |
status: | New → Confirmed |
assignee: | nobody → xingzhou (xingzhou) |
Changed in ceilometer: | |
assignee: | xingzhou (xingzhou) → Julien Danjou (jdanjou) |
status: | Confirmed → In Progress |
Changed in ceilometer: | |
importance: | Undecided → Low |
milestone: | none → havana-3 |
Changed in ceilometer: | |
status: | Fix Committed → Fix Released |
Changed in ceilometer: | |
milestone: | havana-3 → 2013.2 |
@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?