Open Stack

Yeah. I'm not saying any project has done it out of malice. Everyone's just doing whats best for their project. But it does not seem like there is an overarching entity watching over the whole or (pushing, encouraging, enticing, whatever words are appropriate here) projects to work on the commons anymore. It use to be that incubating projects were pushed to help the other projects integrate with them by the incubating project being strongly encouraged to write the integrations themselves as part of the incubation process. Now it seems like each project just spawns and then hopes someone else will do the legwork. Using the carrot of incubation to further the commons is not an ideal solution, but it was at least something.

Linux has an overarching entity, Linus for that task. He's there to make sure that someone is really paying attention to integration of the whole thing into a cohesive, usable whole. Sometimes he pushes back and makes sure commons work happens as part of features getting in to ensure commons work still gets done. I'm not advocating a benevolent dictator for OpenStack though.

But what I thought what the TC's job was, was benevolent dictators, which each subproject (or subsystem in linux terms) are required to give up final say to, so that sometimes the projects have to sacrifice a bit so that the whole can flourish and those benevolent dictators are elected for a time, by the OpenStack community. (Actually, I think  that kind of makes it a Democratic Republic... but I digress) Maybe I misunderstood what the TC's about. But I think we still do need some folks elected by the community to be involved in making sure OpenStack as a whole has a cohesive technical architecture that actually addresses user problems and that have some power to to stop the "this feature belongs in this project", "no, it belongs in that project", "no, lets spawn 3 new projects to cover that case" kinds of things, make the difficult decision, and ask a project to help the community out by going along with "a solution" and we all can move on. Critical features have been stuck in this space for years and OpenStacks competitors have had solutions for years. 

Interest in OpenStack as a whole has leveled off in about:

________________________________________
From: Zane Bitter [zbitter at redhat.com]
Sent: Tuesday, July 19, 2016 1:08 PM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

On 14/07/16 16:30, Fox, Kevin M wrote:
> I'm going to go ahead and ask the difficult question now as the answer is relevant to the attached proposal...
>
> Should we reconsider whether the big tent is the right approach going forward?
>
> There have been some major downsides I think to the Big Tent approach, such as:
>  * Projects not working together because of fear of adding extra dependencies Ops don't already have
>  * Reimplementing features, badly, over and over again in different projects instead of standardizing something.
>  * More projects being created due to politics and not technical reasons.
>  * Less cross project communication
>  * Greater Operator pain at trying to assemble a more loose confederation of projects into something useful.
>  * General pushing off more and more work to Operators/Users to deal with.
>  * Worse User experience as cross project issues aren't being addressed.
>  * Previously incubated projects such as Nova, Swift, etc getting a disproportionate say in things as they have a greater current user base, and its increasingly hard now for new projects to gain any traction.
>  * Much less community pressure on projects to work together to elevate everyone. Architectural decisions are now made at individual project level with little done at the OpenStack level.
>  * etc...

The thing is, all of these problems pre-date the big tent. Arguably they
were even worse before because so many projects were not only not
blessed by the TC as hard dependencies, but officially weren't even part
of OpenStack. Say what you want about the big tent, but at least we
haven't been treated to another Zaqar graduation review farce.

I think your complaint here is that the big tent hasn't done enough to
solve these problems. That's a fair complaint.

I think what you're suggesting is missing is some sort of TC imprimatur
to say that it's acceptable to take a hard dependency on a particular
project, which is effectively what graduation from incubation meant
previously (e.g. distributors were effectively, though not actually,
obliged to package it at this point if they weren't already). Of course
the only thing that can really _force_ people to adopt a project is
DefCore, and that comes with a major chicken-and-egg dilemma. It's true
that we've hollowed out most of the levels between just being "one of
us" and being DefCore-approved.

I worried about this myself at the time the big tent was proposed. But I
don't think it's a silver bullet - developers of new projects have
always been reluctant to take hard dependencies (source: first-hand
experience starting in 2012). It's *hard* to get operators to adopt your
project. To get operators to adopt your project plus some other project
is... well it's definitely never easier.

That said, I don't think any of the projects you mentioned elsewhere
(e.g. the 4 with the own implementations of guest agents) are being
deliberately intransigent. They're each just trying to find a
good-enough solution in isolation. If a standard way of doing guest
agents had existed before they started then I'm confident they (we) all
would have used it, and if one cropped up now I hope none of them would
resist efforts to at least support it as an option (i.e. with only soft
dependencies).

The thing that's not happening, and has never happened, is that nobody
is getting those groups together and trying to come up with a common
standard that everything can move toward. I think Clint's proposed
architecture working group is a step in the right direction here. I
don't know if such questions, which in a sense concern the user-visible
architecture as much as the backend architecture, would be considered in
scope (or high-priority) by that group. It's possible we might need a
separate working group to address the needs of what I've been calling
autonomous applications (i.e. cloud-resident applications that use the
cloud APIs to control their own infrastructure). But I'm reluctant to
formally propose such a thing until we have had a chance to let the
architecture group pioneer the territory :)

cheers,
Zane.

> The overall goal of the Big Tent was to make the community more inclusive. That I think has mostly happened. Which is good. But It also seems to have fractured the community more into insular islands and made the system harder for our operators/users. Which is bad.
>
> Maybe the benefits outweigh the drawbacks. I'm not sure. But I think its probably time to consider if it has been a net positive and should be further refined to try and address some of these problems, or a net negative and different approaches be explored.
>
> Thanks,
> Kevin


__________________________________________________________________________
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