Open Stack

> For the cookbooks, every core and non-core project that is supported has to
> be tracked. In addition to that, each platform that is supported must be
> tracked, for quirks and idiosyncrasies, because they always have them.
>
> Then, there are the cross-project teams that do the packaging, as well as
> the teams that do not necessarily ship releases that must be tracked, for
> variances in testing methods, mirrors outside the scope of infra, external
> dependencies, etc. It can be slightly overwhelming and overloading at times,
> even to someone reasonably seasoned. Scale that process, for every ecosystem
> in which one desires to exist, by an order of magnitude.
>
> There’s definitely a general undercurrent to all of this, and it’s bigger
> than any one person or team to solve. We definitely can’t “read the release
> notes” for this.

Radical idea, have each project (not libraries) contain a dockerfile 
that builds the project into a deployable unit (or multiple dockerfiles 
for projects with multiple components) and then it becomes the projects 
responsibility for ensuring that the right code is in that dockerfile to 
move from release to release (whether that be a piece of code that does 
a configuration migration).

This is basically what kolla is doing (except kolla itself contains all 
the dockerfiles and deployment tooling as well) and though I won't 
comment on the kolla perspective if each project managed its own 
dockerfiles that wouldn't seem like a bad thing... (it may have been 
proposed before).

Such a thing could move the responsibility (of at least the packaging 
components and dependencies) onto the projects themselves. I've been in 
the boat of try to do all the packaging and tracking variances and I 
know it's a some kind of hell and shifting the responsibility on the 
projects themselves may be a better solution (or at least can be one 
people discuss).