[openstack-dev] [tc] [elections] Available time and top priority
Jay Pipes
jaypipes at gmail.com
Tue Apr 11 17:48:26 UTC 2017
On 04/10/2017 02:26 PM, Ed Leafe wrote:
> On Apr 10, 2017, at 4:16 AM, Thierry Carrez <thierry at openstack.org>
> wrote:
>> If there was ONE thing, one initiative, one change you will
>> actively push in the six months between this election round and the
>> next, what would it be ?
>
> Just one? If I had to choose, I would like to see a clear separation
> between the core services that provide IaaS, and the products that
> then build on that core. They occupy very different places in the
> OpenStack picture, and should be treated differently.
Agreed.
> 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).
> Reliability is the key for them. But for the services and
> applications that are built on top of this base? I'd like to see
> allowing them a much more open approach: let them develop in whatever
> language they like, release when they feel the timing is right, and
> define their own CI testing. In other words, if you want to develop
> in a language other than Python, go for it! If you want to use a
> particular NoSQL database, sure thing! However, the price of that
> freedom is that the burden will be on the project to ensure that it
> is adequately tested, instead of laying that responsibility on our
> infra team.
This is *precisely* what the Big Tent was all about: opening up the
"what is an OpenStack project" idea to more newcomers and competing
implementations with the condition that the shared cross-project teams
like docs and infra would be enablers and not doers. Instead of creating
infrastructure for all the new project teams, the infra team would
transition to providing guidance for how the project teams should set up
gate jobs for themselves. Instead of writing documentation for the
project teams, the docs team would instead provide guidance to new teams
on how to write docs that integrate effectively with the existing docs
tooling.
The TC and the Big Tent didn't stop Freezer from making ElasticSearch
its only metadata storage solution. Nobody stopped Gluon and other
projects from using etcd for control plane communication and event
notification. And nobody should be stopping these projects from
innovating and experimenting.
As for the Python versus other languages bit, sure, the TC took some
time to formulate its opinion regarding the impact another language
would have on the OpenStack shared team workload but the Big Tent and
the structure of the TC was not an impediment to discussion of other
languages in the OpenStack ecosystem. Rather, preference for other
(non-Gerrit) workflows and (non-IRC) communication methods continue to
be the primary influencing factors for non-Python projects in the cloud
space.
> 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?
> 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?
Best,
-jay
More information about the OpenStack-dev
mailing list