Open Stack

Excerpts from Fox, Kevin M's message of 2016-07-19 21:59:29 +0000:
> 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.

DefCore has said time and again that they are a trailing indicator,
basing their work on many inputs, including the "technical direction"
of the project.  Adding interdependencies between OpenStack projects
should not be blocked on DefCore. Consider things like whether a
project is mature enough to rely on, has enough contributors to
keep it going, is well tested, etc. Don't wait for DefCore to cover
it.

> 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).

+1

It would be nice to see a working group form to address that and
standardize as much as possible, now that we have several examples of
use cases and a wide range of inputs for requirements.

> 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

+1

> 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
>