<div dir="ltr">Joe,<div><br></div><div>Thanks for the input here. This is useful, and the thread you link to is interesting. No doubt solving this is not easy since you can never really know everything the end user/developer will want for an application build/runtime.</div><div><br></div><div>Some of the ideas in that thread, and in this document [1] that sound the most compelling to me are</div><div><ul><li>Allowing for composability so that the developer can add what they need at image build time. I think that <font face="monospace">.s2i/assemble</font> and friends make this possible, but maybe I am missing something larger. Am I?</li><li>Providing two different s2i base images for each runtime environment: <font face="monospace">s2i-core</font> and <font face="monospace">s2i-base</font>, for example. I think the core image should be similar to rhel7-atomic. Just a bare bones, optimized-for-the-container image. Developers concerned about image size can use this image and <font face="monospace">.s2i/assemble</font> to have a fully customizable build/runtime environment. Developers less concerned about minimal size could depend on <font face="monospace">s2i-base</font> which has all of the tools and development libraries that are generally required for the vast majority of OS/platform/language environments.</li><li>Allow users to specify the runtime image and runtime artifact(s) on the command line, as described in the document linked below. In a contrived/simple case, this would mean that a developer could use <font face="monospace">s2i-base</font> for building the application image and <font face="monospace">s2i-core</font> for the runtime. No customization required, just a simple command line option that builds in a full featured environment and deploys to a slimmed down runtime.</li></ul><div>I think the combination of these three capabilities give the developer a lot of flexibility - maybe all that is needed - in customizing the build and runtime environments for their application. And since <font face="monospace">s2i-base</font> still has the whole kit and caboodle(??!!), you still have a simple, easily demonstrated experience for new users who just want to get to know OpenShift and don't need deep levels of customization/optimization.</div></div><div><br></div><div>My 2c.</div><div>Lance</div><div><br></div><div>[1] <a href="https://github.com/openshift/source-to-image/blob/master/docs/runtime_image.md">https://github.com/openshift/source-to-image/blob/master/docs/runtime_image.md</a></div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Mar 17, 2017 at 11:27 AM Joe Orton <<a href="mailto:jorton@redhat.com">jorton@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Mar 17, 2017 at 02:52:03PM +0000, Lance Ball wrote:<br class="gmail_msg"> > Thanks for the reply Ben. Adding everyone else back in...<br class="gmail_msg"> ><br class="gmail_msg"> > I honestly don't mean to be obtuse here, but I'm still a little confused.<br class="gmail_msg"> > Please bear with me and a couple more questions.<br class="gmail_msg"> <br class="gmail_msg"> I think the list of packages added to s2i-base is exactly the set of<br class="gmail_msg"> things which have been seen to be common across the various language<br class="gmail_msg"> images. BenP & Honza can probably expand on this.<br class="gmail_msg"> <br class="gmail_msg"> We're discussing the same thing over on the RHSCL list, FYI =><br class="gmail_msg"> <br class="gmail_msg"> <a href="http://post-office.corp.redhat.com/archives/rh-software-collections/2017-March/msg00028.html" rel="noreferrer" class="gmail_msg" target="_blank">http://post-office.corp.redhat.com/archives/rh-software-collections/2017-March/msg00028.html</a><br class="gmail_msg"> <br class="gmail_msg"> With the node image the gyp npm module is one we have had "fun" with -<br class="gmail_msg"> it needs Python and a C++ compiler.<br class="gmail_msg"> <br class="gmail_msg"> Regards, Joe<br class="gmail_msg"> <br class="gmail_msg"> ><br class="gmail_msg"> > On Thu, Mar 16, 2017 at 7:40 PM Ben Breard <<a href="mailto:bbreard@redhat.com" class="gmail_msg" target="_blank">bbreard@redhat.com</a>> wrote:<br class="gmail_msg"> ><br class="gmail_msg"> > > I mean that fedora and centos will have versions of the rhel7-atomic<br class="gmail_msg"> > > image. With this we can potentially create smaller s2i and other useful<br class="gmail_msg"> > > things. ...but I have no other insight on who maintains what. sorry<br class="gmail_msg"> > ><br class="gmail_msg"> ><br class="gmail_msg"> > I don't understand how Fedora and CentOS can have "versions of the<br class="gmail_msg"> > "rhel7-atomic" image. Do you mean that there will be "atomic" (and<br class="gmail_msg"> > therefore hopefully, smaller) images for these OSs? So, we'd have something<br class="gmail_msg"> > like fedora-atomic and centos-atomic?<br class="gmail_msg"> ><br class="gmail_msg"> ><br class="gmail_msg"> > > I'm confused why you would need to install httpd, etc in a base builder<br class="gmail_msg"> > > image. Shouldn't a base s2i builder image just be the minimal requirements<br class="gmail_msg"> > > to support runtime execution in the OpenShift environment?<br class="gmail_msg"> > ><br class="gmail_msg"> > > yes!!! Here's the list:<br class="gmail_msg"> > ><br class="gmail_msg"> > > INSTALL_PKGS="autoconf \<br class="gmail_msg"> > > automake \<br class="gmail_msg"> > > bsdtar \<br class="gmail_msg"> > > bzip2 \<br class="gmail_msg"> > > findutils \<br class="gmail_msg"> > > gcc-c++ \<br class="gmail_msg"> > > gd-devel \<br class="gmail_msg"> > > gdb \<br class="gmail_msg"> > ><br class="gmail_msg"> ><br class="gmail_msg"> > Why would a plain vanilla builder image need gdb, gcc, gcc-c++, gd-devel<br class="gmail_msg"> > and make (below)? I suppose for projects that require compilation during<br class="gmail_msg"> > the build step this makes sense. But isn't that specific to a runtime<br class="gmail_msg"> > platform/language? E.g. if I'm running a Ruby application, why on earth<br class="gmail_msg"> > would I want my runtime image to contain gd-devel and gdb? And to be<br class="gmail_msg"> > honest, even for compiled projects, gdb seems a bit overkill for a runtime<br class="gmail_msg"> > build environment.<br class="gmail_msg"> ><br class="gmail_msg"> ><br class="gmail_msg"> > > gettext \<br class="gmail_msg"> > > git \<br class="gmail_msg"> > > libcurl-devel \<br class="gmail_msg"> > > libxml2-devel \<br class="gmail_msg"> > > libxslt-devel \<br class="gmail_msg"> > > lsof \<br class="gmail_msg"> > > make \<br class="gmail_msg"> > ><br class="gmail_msg"> > mariadb-devel \<br class="gmail_msg"> > > mariadb-libs \<br class="gmail_msg"> > ><br class="gmail_msg"> ><br class="gmail_msg"> > Why include MariaDB by default in the builder images? Most projects won't<br class="gmail_msg"> > use this will they? Or is it specific to OpenShift's needs?<br class="gmail_msg"> ><br class="gmail_msg"> ><br class="gmail_msg"> > > openssl-devel \<br class="gmail_msg"> > > patch \<br class="gmail_msg"> > > postgresql-devel \<br class="gmail_msg"> > ><br class="gmail_msg"> ><br class="gmail_msg"> > Same question as above. Why include this unless it's needed by OpenShift<br class="gmail_msg"> > itself.<br class="gmail_msg"> ><br class="gmail_msg"> ><br class="gmail_msg"> > > procps-ng \<br class="gmail_msg"> > > scl-utils \<br class="gmail_msg"> > > sqlite-devel \<br class="gmail_msg"> > ><br class="gmail_msg"> ><br class="gmail_msg"> > Ditto...<br class="gmail_msg"> ><br class="gmail_msg"> ><br class="gmail_msg"> > > tar \<br class="gmail_msg"> > > unzip \<br class="gmail_msg"> > > wget \<br class="gmail_msg"> > > which \<br class="gmail_msg"> > > yum-utils \<br class="gmail_msg"> > > zlib-devel" && \<br class="gmail_msg"> > ><br class="gmail_msg"> ><br class="gmail_msg"> > Devel libs seem unnecessary?<br class="gmail_msg"> ><br class="gmail_msg"> > I guess on the whole, I think the base builder images for any given<br class="gmail_msg"> > operating system should have only enough in them to fulfill OpenShift<br class="gmail_msg"> > requirements. After that, it seems that subsequent builder images that<br class="gmail_msg"> > layer on top of these should be responsible for handling their own<br class="gmail_msg"> > dependencies. So, it's confusing to me why we would need to include all of<br class="gmail_msg"> > this extraneous stuff in the builder images.<br class="gmail_msg"> ><br class="gmail_msg"> > Thanks<br class="gmail_msg"> > Lance<br class="gmail_msg"> --<br class="gmail_msg"> Joe Orton // Red Hat Core Services<br class="gmail_msg"> </blockquote></div></div></div>