Open Stack

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.

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.

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.

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.

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.

Happy to hear your thoughts on this.

Thanks,
Fausto



On Thu, Jan 28, 2016 at 8:55 PM, Ian Wells <ijw.ubuntu at cack.org.uk> wrote:

> 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.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160129/74f519df/attachment.html>