On 27/01/16 12:16 -0500, Emilien Macchi wrote:
On 01/27/2016 10:51 AM, Jay Pipes wrote: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.I agree with you here Jay, Monasca is a great example of failure in having consistency across OpenStack projects. It's a different topic but maybe a retrospective of what happened could help our community to not reproduce the same mistakes again. Please do not repeat this failure for other projects. Do not duplicate efforts: if Ekko has a similar mission statement, maybe we should avoid creating a new project and contribute to Freezer? (I'm probably missing some technical bits so tell me if I'm wrong)
FWIW, the current governance model does not prevent competition. That's not to be understood as we encourage it but rather than there could be services with some level of overlap that are still worth being separate. What Jay is referring to is that regardless the projects do similar things, the same or totally different things, we should strive to have different APIs. The API shouldn't overlap in terms of endpoints and the way they are exposed. With all that said, I'd like to encourage collaboration over competition and I'm sure both teams will find a way to make this work. Cheers, Flavio -- @flaper87 Flavio Percoco
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
