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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
