[openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack
flavio at redhat.com
Wed Jan 27 19:06:08 UTC 2016
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. you will
>>> definitely want to coordinate the naming of your messages. ie.
>>> event_type == backup.<ekko_scope> and event_type ==
>> 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 
>> and Monasca  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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the OpenStack-dev