[openstack-dev] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef
harlowja at fastmail.com
Thu Feb 16 05:25:17 UTC 2017
> 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
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
More information about the OpenStack-dev