Re: [atomic-devel] 3 kinds of "docker build"

[Clayton Coleman <ccoleman redhat com>]

> On Oct 16, 2014, at 9:10 AM, Colin Walters <walters verbum org> wrote:
> 
> One thing I find strange about STI myself is that the unit of
> interaction is the Docker image, and the source code is an external
> thing you supply. 
> 
> To me, Docker images are *caches* of source code built in a specific
> configuration.  Source code is git repositories, pinned to specific
> revisions.
> 
> I think source code (+ build configuration) should be the focus, or unit
> of interaction.  Most packaging systems I've seen are also wrong in this
> - they has an obsessive focus on the metadata, the actual source code is
> just a Source0: line, squirrelled away in the lookaside cache or
> similar.
> 
> While I understand the rationale behind STI's focus on the
> build-one-thing, a case I was hitting is this:
> 
> I have two Docker images (apps I'm working on), with a common set of
> packages shared between them, both deriving from a well-known framework
> (base image).  The common set here might include say a configuration or
> utility library I wrote.  If I'm working on one of my apps and fix
> something in the utility library, I want to potentially rebuild/retest
> both images.
> 
> Here's a real-world example:
> https://github.com/stackforge/kolla/blob/master/docker/fedora-rdo-base/Dockerfile
> 
> Now that Docker file is just an *assembly*, whereas I as an app author
> will want to build from source.  Say the author of Glance also needs to
> update "python-jsonpatch" (to pick a random example).  Clearly in the
> glance Dockerfile they could test this by just doing a yum install of
> their custom RPM, but I think a more intelligent build system would be
> capable of building the python-jsonpatch from *source*, in addition to
> taking a custom RPM.
> 
> I think this is a quite reasonable real-world scenario that also
> highlights the full complexity of the kind of build system I think we
> need.  The system could build python-jsonpatch as a standalone RPM, then
> be capable of efficiently injecting that updated RPM into derived
> images.

I think the big question is whether that's the common use case.  Part of why STI exists is that the vast majority of software intended for web deployment (directly, vs as libraries) has no real need for RPM other than as a mechanism to verify the exact version deployed.  So STI focuses on ensuring a repeatable environment and encapsulation of the build concern, in the same way that brew hides/abstracts some of the details of creating a chroot, taking a Git repo and converting it to an output RPM.  The input build image is the build-requires.

I agree the flow you're describing is useful, but is it the important flow for all audiences?