Open Stack

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