Open Stack

On Thu, Dec 14, 2017 at 10:37 AM, Doug Hellmann <doug at doughellmann.com> wrote:
> What would our world look like if we treated inter-service dependencies like
> we do service-to-library dependencies and only integration test released
> components, rather than installing everything from source by default?

I've been struggling to catch up and haven't gotten through the office
hours log yet, but this summarizes the thing that keeps bounding
through my mind.  But it seems to me that much of the reaction to
ttx's proposal gets into things that are not directly
development-cycle-related.  It feels like we are continuing to treat
symptoms and not actually address root causes.

I think #1 on our top-wanted list for the Board needs to be to address
these root causes.  Continuing to not do this will become an
existential problem for OpenStack.  Look at the situation with Nova
and the amount of energy spent on trying to improve things there
without actually being able to address the real problems.  Some of
these problems are structural to the software, some of them are the
massive amount of inertia that a 6 year old project that needs to be
backward-compatible  inevitably carries.

The dev cycle discussion is (to pick a number) 80% focused on the
problems related to Nova: upgrade times, release deployment time, etc.

Clint brought up Swift earlier in the thread, and I think that is the
counter-example of what can happen with well-defined interfaces and
stable APIs.  Swift has been successful from the start with their
release model and fitting it into the overall OpenStack releases.
Why?  Because it does one thing, does it damn well, and does it with a
VERY stable API.  Some of the newer projects have also been able to
operate in this mode.

Even with the differences in how they were created, Cinder and Neutron
are still tightly tied to Nova in terms of upgrades and the
requirements to keep them coordinated in specifically controlled
releases.

Outside of those three projects, what others are experiencing the
sorts of problems being discussed here?  Is this (mostly) only a
problem the three largest and tightly-coupled projects?  In the
current environment I do not see any of our corporate sponsors
stepping up to un-couple those three, but for the rest it seems like
Doug's suggestion goes a long way toward addressing problems being
brought up here.

dt

-- 

Dean Troyer
dtroyer at gmail.com