Open Stack

On 01/27/2016 12:53 PM, gordon chung wrote:
>> It makes for a crappy user experience. Crappier than the crappy user
>> experience that OpenStack API users already have because we have done a
>> crappy job shepherding projects in order to make sure there isn't
>> overlap between their APIs (yes, Ceilometer and Monasca, I'm looking
>> directly at you).
> ... yes, Ceilometer can easily handle your events and meters and store
> them in either Elasticsearch or Gnocchi for visualisations. you just
> need to create a new definition in our mapping files[1][2]. you will
> definitely want to coordinate the naming of your messages. ie.
> event_type == backup.<ekko_scope> and event_type == backup.<freezer_scope>.

This isn't at all what I was referring to, actually. I was referring to 
my belief that we (the API WG, the TC, whatever...) have failed to 
properly prevent almost complete and total overlap of the Ceilometer [1] 
and Monasca [2] REST APIs.

They are virtually identical in purpose, but in frustrating 
slightly-inconsistent ways. and this means that users of the "OpenStack 
APIs" have absolutely no idea what the "OpenStack Telemetry API" really is.

Both APIs have /alarms as a top-level resource endpoint. One of them 
refers to the alarm notification with /alarms, while the other refers to 
the alarm definition with /alarms.

One API has /meters as a top-level resource endpoint. The other uses 
/metrics to mean the exact same thing.

One API has /samples as a top-level resource endpoint. The other uses 
/metrics/measurements to mean the exact same thing.

One API returns a list JSON object for list results. The other returns a 
dict JSON object with a "links" key and an "elements" key.

And the list goes on... all producing a horrible non-unified, 
overly-complicated and redundant experience for our API users.

Best,
-jay

[1] http://developer.openstack.org/api-ref-telemetry-v2.html
[2] 
https://github.com/openstack/monasca-api/blob/master/docs/monasca-api-spec.md