Open Stack

On 1/27/16, 12:06 PM, "Flavio Percoco" <flavio at redhat.com> wrote:

>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

Flavio,

Of course you know this, but for the broader community that may not be
aware, the exact governance repo line item is as follows:
"

* Where it makes sense, the project cooperates with existing projects
rather than gratuitously competing or reinventing the wheel

"

Now that line could be interpreted in many ways, but when Kolla went
through incubation with at least 5 other competitors in the deployment
space, the issue of competition came up and the TC argued that competition
was a good thing on the outer-layer services (such as deployment) and a
bad thing for the inner layer services (such as nova).  The fact that APIs
may be duplicated in some way is not an optimal situation, but if that is
what the TC wishes, the governance repository for new projects should be
updated to indicate the guidelines.

Sam and the EKKO core team's work is creative, original, and completely
different then freezer.  The only thing they have in common is they both
do backups.  They fundamentally operate in different ways.

The TC set precedent in this first competition-induced review which is
worth a good read for other projects thinking of competing with existing
projects of which there are already plenty in OpenStack..

https://review.openstack.org/206789


My parsing of the Technical Committee precedent set there is if the
project is technically different in significant ways, then its A-OK for
big-tent inclusion down the road and definitely suitable for a new project
development effort.

Sam and the EKKO core team's work is creative, original, and completely
different then freezer.  The only thing they have in common is they both
do backups.  They fundamentally operate in different ways, meeting the
intent of the Technical Committee in that big tent review.  They are not
gratuitously competing or reinventing the wheel.  They are putting tires
on the wheel so the software behaves correctly on the road.  In my
technical opinion Ekko cannot be grafted into freezer.


Choice is one of life's fundamental elements that make life interesting.
Let the Operators choose what they wish based upon technical merits rather
then "who was first to publish a project".

Regards
-steve

>