<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 27 January 2016 at 11:06, Flavio Percoco <span dir="ltr"><<a href="mailto:flavio@redhat.com" target="_blank">flavio@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">FWIW, the current governance model does not prevent competition. That's not to<br>
be understood as we encourage it but rather than there could be services with<br>
some level of overlap that are still worth being separate.<br></blockquote><div><br></div><div>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.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

What Jay is referring to is that regardless the projects do similar things, the<br>
same or totally different things, we should strive to have different APIs. The<br>
API shouldn't overlap in terms of endpoints and the way they are exposed.<br></blockquote><div><br></div><div>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.<br><br></div><div>[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.]<br></div><div><br></div><div>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.<br> <br>-- <br></div><div>Ian.<br></div></div></div></div>