Open Stack

On 27 January 2016 at 11:06, Flavio Percoco <flavio at redhat.com> wrote:

> 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.
>

There should always be the possibility to compete; it's always possible
that rethinking an idea produces a better implementation of the same API.
But we don't separate API from implementation in Openstack - the 'XXX API'
cannot easily be divorced from the project containing the implementation
when the definition of the 'XXX API' is 'the API implemented by the XXX
code'.  We should separate them - the API is the only thing that a tenant
will ever actually care about, not the implementation choice behind it.

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.
>

And for this, perhaps we should have an API namespace registry, so that
when two groups implement the same endpoints they have to implement the
same API?  I think Jay's point is that we muddy the waters here by having
confusingly similar-but-different APIs.

[The counterargument is that service discovery usually determines what API
you're getting, so that if two services claim to be different service types
in Keystone then they are *not* the same API and should be allowed free
reign of their URI namespace, but I see that's not working for us.]

And, coming back to the original point, if Freezer and Ekko both implement
backups, and they can come to an agreement on what 'a backup' is and an API
definition for it, that means that they could exist as independent projects
with independent codebases that both implement /backup - but, importantly,
in a consistent way that doesn't confuse app developers.  That will only
work if the API definition stands separate from the projects, though.

-- 
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160128/3aad56be/attachment.html>