On Thu, Feb 11, 2016, at 05:00 PM, Clayton Coleman wrote: > > I really want to look at making this a first class build path in OpenShift - > it has a ton of advantages for builds of base images, and enables admins to > slice and dice their toolchains. The question that has held it up so far is > what API surface does it need - maybe make s2i capable of leveraging the > concepts
There are a lot of high level issues here. One is that rather intentionally, "rpm-ostree container" is *not* what I would call a build system. Merely a "reassembly". It doesn't even support arbitrary %post like kickstart does right now - executing arbitrary code makes it much harder to detect when things have changed, although the simplest is to store your post scripts in git, then define "changed" as git commit changed. It's a very artifact-focused view - the "images" are just automatically derived from the input artifacts. So for example, even your application is an RPM, and its dependencies form the image. This becomes a lot more palatable when constructing buildroots for the artifacts is fast too with ostree hardlinks rather than yum install. So the true "build" is the part that processes git repositorie(s) to generate artifacts. After that it's just triggering reassembly + rolling deployment updates. That said though, a hybrid model is to have this tool generate base images for S2I. If you look at: https://blog.openshift.com/create-s2i-builder-image/ It's this part that looks like the only thing requiring it to run as root: RUN yum install -y lighttpd && \ # clean yum cache files, as they are not needed and will only make the image bigger in the end yum clean all -y Which is a thing rpm-ostree container fixes.
