RepoFunnel and the Software Component Pipeline

[Nick Coghlan]

On 25 August 2015 at 07:35, Colin Walters <walters at verbum.org> wrote:
> On Sun, Aug 23, 2015, at 10:42 PM, Nick Coghlan wrote:
>> Filtered repo definitions, by contrast, are very easy to federate
>> across different users, and very easy to consume when building
>> container and machine images (regardless of the image creator's
>> preferred choice of configuration management tool).
>
> Maybe...if what you're saying is "installing 1-3 files in /etc/yum.repos.d
> is easier than 5-10", possibly, although I myself haven't seen large
> numbers there.

Yeah, I actually gave a really bad explanation that had nothing to do
with how I originally became interested in the idea, but rather with
my objection to the notion of needing to learn config management tools
just to have more than one computer :)

The RepoFunnel concept itself more comes from an idea Stephen Tweedie
mentioned to me just before Flock2Fedora: the notion of an RPM repo as
a modular build artefact in its own right. If we're looking at it in a
layered container context, we might think of constructing our
applications this way:

= S2I repo
== App-specific deps
=== Language runtime
==== Base Image

How do we define what goes into the base image? An RPM repo. The
language runtime layer? An RPM repo. The application specific
dependencies layer? An RPM repo (or some other packaging system). Only
at the uppermost layer of the image would we resort to pulling source
code directly from a git repo in order to tie all those dependencies
together into a coherent application.

Similarly, at the host layer, the contents of a machine image or an
rpm-ostree build conceptually have their origins in an RPM repo that
defines the package set to be included.

Koji has an integrated version of this in its tagging system, but COPR
doesn't really have an equivalent yet. The RepoFunnel proposal adds
that capability, but in a way where the funnel can offer self-service
repositories that don't *necessarily* have to be getting all of their
content from COPR (for example, plugins like pulp-python could later
be used to offer self-service filtered PyPI mirrors).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia