Open Stack

On 3 May 2014 08:26, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:
> There is only one other programming project I know on the same scale as
> OpenStack, the Linux Kernel, and it has gone through the same exact
> situation. Its best to learn from them. The push/pull between Developers and
> Users problem.
>
> A number of years back, the Kernel guys solved it largely by clearly
> delineating the situation:
>
> * Mainline is not for users! Its for developers. The develops have to take
> the long game into account and plan on maintaining the software for many
> many years. This means sometimes functionality must suffer in order to keep
> the whole thing maintainable. If this is not done though, the whole thing
> falls apart. In a decade, the users won't want to use the code if the
> maintainability suffers to much. Users usually don't think through the long
> game though. Don't force the developers to accept bad patch after bad patch
> because "it makes our system just work". Operators will pay the ultimate
> cost eventually.
>
> * Distro's take whats in mainline and add pragmatic, often dirty, patches in
> order to produce a system operators desire to use. Then the distro's work
> with the upstream developers to produce proper, maintainable solutions.
>
> I know some folks in the community have been recommending to Operators to
> use mainline (particularly the TripleO project), and that is, IMHO a huge
> mistake.

Actually, we started with Operators that wanted to run mainline, and
we're working from there back to dealing with releases. TripleO
intends to be able (at any point in time) to deploy current trunk and
current stable release of OpenStack. Both of these are common use
cases with Operators.

I have and remain a huge advocate for trunk being *production ready*,
because if its not, you're looking at *another* 3-6 months of work
post release to fix things up. OpenStack is big, with many
interactions, and if we let things get bad it gets bad very very fast.
Bad like 'we can't deploy even 30 machines in a Heat cluster' (the
latest case where something that wasn't tested blew out).

It's important to have the horse before the cart though:
1) Establish accurate timely feedback to projects about the production
suitability of their code.
2) Make it possible to deploy trunk with defaults
3) Make trunk being production suitable a non-voting check
4) Make it a gate
5) *Consider* recommending folk fitting the gated cases run trunk.

We're between 2 and 3 at the moment in TripleO at the moment - we have
check jobs but we don't have resources to run them on every
nova/keystone/etc commit, and they're not running at scale yet (2
hypervisors isn't @scale). We had lots of offers of resources last
summit but sadly only RedHat followed through - and this is now a
significant limitation for us.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud