[openstack-dev] [nova][neutron][cinder] Averting the Nova crisis by splitting out virt drivers

James Bottomley James.Bottomley at HansenPartnership.com
Thu Sep 11 15:40:05 UTC 2014


On Thu, 2014-09-11 at 16:20 +0100, Duncan Thomas wrote:
> On 11 September 2014 15:35, James Bottomley
> <James.Bottomley at hansenpartnership.com> wrote:
> 
> > OK, so look at a concrete example: in 2002, the Linux kernel went with
> > bitkeeper precisely because we'd reached the scaling limit of a single
> > integration point, so we took the kernel from a single contributing team
> > to a bunch of them.  This was expanded with git in 2005 and leads to the
> > hundreds of contributing teams we have today.
> 
> 
> One thing the kernel has that Openstack doesn't, that alter the way
> this model plays out, is a couple of very strong, forthright and frank
> personalities at the top who are pretty well respected. Both Andrew
> and Linux (and others) regularly if not frequently rip into ideas
> quite scathingly, even after they have passed other barriers and
> gauntlets and just say no to things. Openstack has nothing of this
> sort, and there is no evidence that e.g. the TC can, should or desire
> to fill this role.

Linus is the court of last appeal.  It's already a team negotiation
failure if stuff bubbles up to him.  The somewhat abrasive response
you'll get if you're being stupid acts as strong downward incentive on
the teams to sort out their own API squabbles *before* they get this
type of visibility.

The whole point of open source is aligning the structures with the
desire to fix it yourself.  In an ideal world, everything would get
sorted at the local level and nothing would bubble up.  Of course, the
world isn't ideal, so you need some court of last appeal, but it doesn't
have to be an individual ... it just has to be something that's
daunting, to encourage local settlement, and decisive.

Every process has to have something like this anyway.  If there's no
process way of sorting out intractable disputes, they go on for ever and
damage the project.

James





More information about the OpenStack-dev mailing list