[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [atomic-devel] RFC Upstream Docker Layered Image Build tooling

Some really good points.  Part of the interesting place where we are at is that the feature set today is very targeted at images.  But let's look to the next steps - what is the best way to build an RPM?  In a container of some sort (happens to be a chroot today).  Do RPM builds need the ability to run on a farm of worker nodes, get logs, etc?  Definitely.  ISOs?  Yup.

I am *not* advocating replacing existing build systems that already do all of these things well.  However, part of the reason we targeted this use case is that the end state for container cluster management, Kubernetes, and OpenShift, is an environment where all of these things can be run.  Rather than assume that every build system out there has to implement a worker node solution - design a platform that allows you to run any linux processes in a controlled and containerized way.  Linux processes that run builds are just one type of process.  That long term goal is certainly not achieved yet - but I would be lying if I didn't say that I truly believe that is the future.  The gotchas are going to be the tricky details - how easy is it to run your chroot jail inside a container and build it, then extract the output?  Finding those gotchas is really important to us, because it helps us understand what to prioritize.

Is it worth it for Fedora or CentOS to make investments in that future right now and help steer the direction?  Certainly worth it to help steer it - but making an investment is something only Fedora or CentOS can answer. 

On Wed, Jul 15, 2015 at 1:15 PM, Adam Miller <maxamillion fedoraproject org> wrote:
On Wed, Jul 15, 2015 at 10:54 AM, Clayton Coleman <ccoleman redhat com> wrote:
> When you say "run / maintain the entire PaaS", can you describe the portions
> of the PaaS that you don't want to run?  You need worker nodes (with Docker
> installed) to build docker images, an agent on each node (to manage the
> docker image builds), and a central server to have an API for starting /
> scheduling / running builds.  For a small deployment, that's what OpenShift
> is providing.  Is it concerns with SDN (which you don't need for builds), or
> the registry (which you don't need), or the router (which you don't need)?
> I would hope that you would be able to run just the bits you need for image
> builds in OpenShift on their own.
> I can certainly understand there are gaps in build functionality.  Part of
> the original goal here was to build something that would be useful to people
> who needed to build images in a farm, with a long term goal of being able to
> manage other types of workloads.  I don't think it's true that the build
> system exists only to serve the PaaS - we plan on using it for other things,
> like hosting builds securely for others.
> Are you saying that long term, you don't believe that a generic compute
> service that happens to have very close ties to Docker, has integrated
> metering, usage, security, and quota, and is supported on a wide range of
> platforms, is *not* a good tool to use to build images?

Ultimately, I'm not trying to say that OpenShift is bad at building
docker containers, it does that just fine. What I'm trying to get at
is that I'm not certain it makes sense for environments with
pre-existing build systems that produce many types of build artifacts
(RPMs, ISO installers, cloud images, vagrant boxes, rpm-ostrees, etc)
to stand up a completely new build system for just one build artifact
type, especially when atomic-reactor can perform the desired task at
face value and could be integrated directly into the existing build

So yes, if you need a stand alone docker layered image build service
in a generic sense such that you don't have a build system in place,
then absolutely OSBS is a great solution. However, for the distro
release engineering teams this is only a single build artifact among


> On Wed, Jul 15, 2015 at 10:15 AM, Adam Miller
> <maxamillion fedoraproject org> wrote:
>> Hello all,
>>     Something that is in the works in Fedora right now is the Docker
>> Layered Image Build Service[0], and we've been looking at using
>> OSBS[1][2] for this but the more we dig into it there is uncertainty
>> about the OpenShift[3] component being the best solution for a build
>> system. OpenShift is a great Platform as a Service(PaaS) cloud
>> environment that happens to feature the logic for scheduling container
>> builds, but that function exists to enable other functionality in the
>> PaaS. Meanwhile from an administrative perspective, we have to
>> run/maintain the entire PaaS to use an extremely tiny subset of it's
>> functionality.
>>     I spoke with KB from the CentOS team to try and get some
>> notes/pointers on OSBS because as I understood it, the CentOS team
>> already gone through a setup of the system before. As we spoke I
>> mentioned my concerns about the overhead and complexity of using a
>> full blown PaaS just for build scheduling and it turns out the CentOS
>> team shares those concerns. Also, the CentOS team largely just uses
>> atomic-reactor[4] on it's own outside of OSBS currently because of the
>> PaaS overhead (at this time, they are still using a version under the
>> previous name of "dock" but that's more or less just a side detail).
>> Using atomic-reactor as close to at face value as possible is
>> something that we on the Fedora Team are also interested in pursuing
>> because the atomic-reactor functionality is great for layered builds,
>> it's simple/concise, has a very clean code base, and it has a very
>> good python API.
>>     Largely as a side note, I attempted to dig into things a little
>> bit and found that there was originally a smaller in scope
>> builder/scheduler service being worked on called dbs[5][6][7] which is
>> based around Celery[8] but this project was left behind in favor of
>> using OpenShift for OSBS.
>>     All that being said, I wanted to start a discussion around the
>> topic to see if there is something that we could all work on
>> collectively upstream to target the very specific need of performing
>> these kinds of builds using atomic-reactor in a way that Fedora,
>> CentOS, and $others could benefit from using and collaborating on
>> contributions. Whether that be to investigate dbs and possibly
>> "resurrect" that work or fork (if necessary) to continue development,
>> or pursue something entirely new. The end goal would be that we could
>> collaborate on as much as possible and not re-invent build tooling for
>> the different distros. Also, it might be nice if this tooling could
>> build nulecule[9] apps.
>> Please let me know what your thoughts are on the topic. If there's
>> something I'm not thinking of or if the idea of removing OpenShift
>> from the build tooling seems completely crazy, please let me know why
>> because it's certainly possible I'm missing something and I'm always
>> open to new ideas.
>> Thank you,
>> -AdamM
>> [0] -
>> https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
>> [1] - https://github.com/projectatomic/osbs-client
>> [2] - https://github.com/projectatomic/ansible-osbs
>> [3] - https://github.com/openshift/origin
>> [4] - https://github.com/projectatomic/atomic-reactor
>> [5] - https://github.com/DBuildService/dbs-server
>> [6] - https://github.com/DBuildService/dbs-worker
>> [7] - https://github.com/DBuildService/dbs-client
>> [8] - http://www.celeryproject.org/
>> [9] - https://github.com/projectatomic/nulecule
> --
> Clayton Coleman | Lead Engineer, OpenShift

Clayton Coleman | Lead Engineer, OpenShift

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]