On Apr 11, 2017, at 12:48 PM, Jay Pipes <jaypi...@gmail.com> wrote:

>>  The IaaS parts
>> (and yes, I know that just which parts these are is a whole debate in
>> itself) should be rock-solid, slow-moving, and, well, boring.
> 
> A fine idea. Unfortunately, what the majority of end users keep asking for is 
> yet more features, especially features that expose more and more internals of 
> the infrastructure and hardware to the power user (admin or orchestrator).

And they always will. But my point was that those things should be added 
without causing the existing system to become unstable. Stability of the 
foundation allows for much more interesting things to be built on top.

> This is *precisely* what the Big Tent was all about:

Totally agree! The key word, unfortunately, is "was". I don't believe that we 
have seen the results to the degree that we envisioned.

I would add that it isn't simply the choice of tools or language, but also 
their API. Monasca had an uphill struggle because some of their API overlapped 
with other projects, especially Ceilometer. Never mind that it might offer a 
better solution than something like Ceilometer; since Ceilometer was there 
first, Monasca  I would prefer to see these projects be free to develop good, 
solid APIs, and if there is functional overlap or API overlap, so be it. This 
avoids the "first one wins" hurdle. Let each project stand on their own merits. 
If it isn't better than what already exists, no one will use it and it will 
wither away. But if it is better, then that makes our ecosystem that much 
richer.

>> > Such projects will also have to accept a tag such as
>> 'experimental' or 'untested' until they can demonstrate otherwise.
> 
> This already exists, in a much more fine-grained fashion, as originally 
> designed into the concept of the Big Tent:
> 
> https://governance.openstack.org/tc/reference/tags/index.html
> 
> Are you just recommending that the TC controls more of those tags?


Yes! One of the thing that was painful to watch in the tag development process 
was the strong aversion to saying anything that might be considered negative 
about a project, as if stating that, say, a project wasn't fully tested would 
hurt someone's feelings. A more open development environment will require such 
technical evaluations, and not all will be positive. The TC should definitely 
work on making this happen.

>> This can also serve to encourage the development of additional
>> testing resources around, say, Golang projects, so that the Golang
>> community can all pitch in and develop the sort of infrastructure
>> needed to adequately test their products, both alone and in
>> conjunction with the IaaS core of OpenStack. The only thing that
>> should be absolute is a project's commitment to the Four Opens. There
>> will be winners, and there will be losers, and that's not only OK,
>> it's how it should be.
> 
> I'm not grasping how the above doesn't already represent the state of the 
> OpenStack governance world?

It's a matter of emphasis. There wasn't any governance that said that a 
project's API can't overlap with an existing project, but that was the message 
that the TC sent to Monasca. This should be changed to a positive statement 
about encouraging competition and new approaches. I'd like the Four Opens to 
remain an absolute, but that's about it. Duplicated effort? Solving the same or 
a similar problem as another project? Those things shouldn't matter (outside of 
the IaaS core projects). Teams should be free to decide if working with another 
team is the best approach, or going it alone, for example.


-- Ed Leafe





Attachment: signature.asc
Description: Message signed with OpenPGP

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to