Open Stack

On Apr 11, 2017, at 12:48 PM, Jay Pipes <jaypipes at 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





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170411/9baf6cc4/attachment.sig>