<div dir="ltr"><div>What motivates me every day and every night, is to provide the most advanced solution for a set a problems to solve, Open Source and in OpenStack. What motivates me is to work with brilliant people like minded, capable of doing great things working together. It is not the competition and It is not the PTL or Core label that gives you that.<br><br></div><div>In OpenStack most of the time, new project born because there's a group of people in a company that needs to provide a solution for a set of problems, and the same people/company allocate resources, time and efforts. Now if every company start his own project, we are likely to going to have many individual tools to provide a similar set of solutions. Is this what we want? I hope not.<br><br>Starting new projects is a tremendously hard work and with limited resources most of the time. So why not join, work as a community, provide a remarkable service/tool and secure the result for who decide to use OpenStack.<br><br>We have to do the effort of trying hard to work together, smooth differences, improve others rather than block them. Honestly as a PTL I try to do that, every single bloody day, dealing with managers, companies, customers, engineers, code, bugs and community. However I do not think a PTL should be elected 2 consecutive times, for official projects, because it's a great experience that anyone that deserve it, should learn from. But this is just my opinion.<br><br></div><div>That said, what we are trying to do, with Sam (that is showing an open attitude and constructive approach), is to understand if the solution make sense itself, if we can work together as a Team and if it make sense to include it in Freezer. If not, it is crystal clear, that no one in the world, can stop a very committed and capable person to do what he/she wants to do. Even less in the Open Source and here. We probably need to avoid fragmentation and at the same time no limiting new ideas, but potentiate them.<br><br></div><div>Happy to hear your thoughts on this.<br></div><div><br></div><div>Thanks,<br></div><div>Fausto<br></div><div><div><div><div class="gmail_extra"><br><br><br><div class="gmail_quote">On Thu, Jan 28, 2016 at 8:55 PM, Ian Wells <span dir="ltr"><<a href="mailto:ijw.ubuntu@cack.org.uk" target="_blank">ijw.ubuntu@cack.org.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></span><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.<span class=""><font color="#888888"><br> <br>-- <br></font></span></div><span class=""><font color="#888888"><div>Ian.<br></div></font></span></div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div></div></div></div>