<div dir="ltr">Catching up on this.<div><br></div><div>Yes, the intention is as stated by John Doyle.</div><div><br></div><div>With regards to using the 'base' name my intention was to make flag it as an image which you should always be building on top, or as a base for your application.</div><div><br></div><div>or as on Scott's blog </div><div><i><span style="color:rgb(100,100,100);font-family:overpass,Arial,sans-serif;font-size:14px;line-height:21px">The sole purpose of a base image is to provide a starting place for creating your derivative images. When using a </span><span class="" style="color:rgb(100,100,100);font-family:overpass,Arial,sans-serif;font-size:14px;line-height:21px"><a class="" href="https://www.google.com/url?q=http://developers.redhat.com/blog/2014/05/15/practical-introduction-to-docker-containers/%23dockerfilecommit&sa=D&ust=1452618511761000&usg=AFQjCNG7B-C9NlORY1Srmwxx7dHDOfJ6-Q" style="color:rgb(8,192,252);text-decoration:none;line-height:inherit;word-wrap:break-word;background-color:transparent">Dockerfile</a></span><span style="color:rgb(100,100,100);font-family:overpass,Arial,sans-serif;font-size:14px;line-height:21px">, the choice of which base image you are using is explicit:(...)</span></i><br></div><div><br></div><div>Our OpenShift images today have multiple parent images, IIRC, they are: base os, jdk, eap, openshift</div><div><br></div><div>Maybe drop any definition and just call it 'whatever product' image. </div><div><br></div><div>As to who should be creating the images, so far the MW images have been created by the Cloud Enablement (Kevin's team), and as I understand the intention is to slowly handover this task to the individual products. I don't se</div><div><br></div><div>Today we only have images supported under the context of OpenShift, which means they include OpenShift specific bits. I've been getting constant requests, even from OpenShift customers, to provide clean/naked/standalone images of the MW products that contain no runtime specific content, meaning no OpenShift specialization, or thinking from the top-down, EAP should drive what's required in the image, meaning that it would be a JDK, and it's dependencies, and a base os.</div><div><br></div><div>To your point on what base image (top parent 'base image' meaning), it has been RHEL all along, so I would not worry about that. </div><div><br></div><div>D.</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 24, 2016 at 11:03 AM, John Doyle <span dir="ltr"><<a href="mailto:jdoyle@redhat.com" target="_blank">jdoyle@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, May 24, 2016 at 10:48 AM, Scott McCarty <<a href="mailto:smccarty@redhat.com">smccarty@redhat.com</a>> wrote:<br>
><br>
><br>
> On 05/24/2016 10:38 AM, Brent Baude wrote:<br>
><br>
> Comments inline...<br>
><br>
> On Tue, 2016-05-24 at 09:49 -0400, Scott McCarty wrote:<br>
><br>
> All,<br>
>      Last week at the container interlock, one of you (sorry, can't<br>
> remember who, maybe Diogones?) was talking about the Middleware team<br>
> building "base images" which contained VMs.  As a follow up, I wanted<br>
> to understand what was meant by that. I think one of two things could<br>
> be happening, but I didn't want to rat hole the presentation.<br>
><br>
> 1. We are not using the word base image correctly?<br>
> 2. We are planning on releasing Middleware base images?<br>
> 3. More complicated. Relies on RHEL, but squashed (still has a base<br>
> image of RHEL)<br>
><br>
> If #1, check out this article [1] which I did a ton of homework on<br>
> and references Docker's documentation, which defines a base image as<br>
> an image with no parent layer.<br>
><br>
> That is the definition I also tend to favor.  I also tend to only<br>
> associate base images with distributions/OS's.<br>
><br>
> If #2, I think the RHEL team and the middleware team should talk. I<br>
> believe we really need to make sure all software in Red Hat products<br>
> rely on the RHEL "base image" and should probably NOT be creating<br>
> their own base images.<br>
><br>
> Agree completely.  However, if all RH middleware images contained a<br>
> significant, similar set of additional packages/configuration, it might<br>
> make sense to have a RH middleware layered image based on the official<br>
> base-image.  This theoretically could make life easier for folks.<br>
><br>
><br>
> +1 on "layered image" nomenclature<br>
<br>
</div></div>I think the idea was to put a name on a particular layer, and then<br>
attach support and maintenance to that named layer.<br>
<div class="HOEnZb"><div class="h5"><br>
> +1 on building a tree structure (e.g. MW core build).<br>
><br>
><br>
> If #3, I think we should discuss what we message to the world<br>
> (especially customers) about how these are built and we should<br>
> probably be careful calling them base images. Perhaps, something like<br>
> an Application Image or Composed Image? Perhaps talking about how<br>
> they an be used as base images, but are actually rely on a RHEL base<br>
> image? It might not seem important in this small case, but I foresee<br>
> massive confusion if we don't perfectly align now before we 1000s of<br>
> images (currently at just over 100 and growing fast).<br>
><br>
> In the dev world, we have called these "layered images."  But agree,<br>
> some sort of name could make messaging clearer.<br>
><br>
> +1 I have used these in my vocabulary for a while. Also, use that in my<br>
> public articles. I would be more than happy to standardize on that. Just<br>
> left it a bit open as I know that "nameing" things can drive people into a<br>
> tailspin, and I am open to peoples ideas. That said, I think the ship has<br>
> sailed and I am not sure Red Hat is "really" in a place to dictate the<br>
> nomenclature. Much easier to just "go with the flow" and make sure we all<br>
> start using the same language as not to confuse each other. Per my first<br>
> three items, I genuinely wasn't sure what was meant by "base image"...<br>
><br>
> Best Regards<br>
> Scott M<br>
><br>
> [1]: <a href="http://developers.redhat.com/blog/2016/01/13/a-practical-introdu" rel="noreferrer" target="_blank">http://developers.redhat.com/blog/2016/01/13/a-practical-introdu</a><br>
> ction-to-docker-container-terminology/<br>
><br>
> --<br>
> Scott McCarty, RHCA<br>
> Technical Product Marketing: Containers<br>
> Email: <a href="mailto:smccarty@redhat.com">smccarty@redhat.com</a><br>
> Phone: <a href="tel:312-660-3535" value="+13126603535">312-660-3535</a><br>
> Cell: <a href="tel:330-807-1043" value="+13308071043">330-807-1043</a><br>
> Web: <a href="http://crunchtools.com" rel="noreferrer" target="_blank">http://crunchtools.com</a><br>
> When should you split your application into multiple containers? http<br>
> ://<a href="http://red.ht/22xKw9i" rel="noreferrer" target="_blank">red.ht/22xKw9i</a><br>
><br>
><br>
> --<br>
><br>
> Scott McCarty, RHCA<br>
><br>
> Technical Product Marketing: Containers<br>
><br>
> Email: <a href="mailto:smccarty@redhat.com">smccarty@redhat.com</a><br>
><br>
> Phone: <a href="tel:312-660-3535" value="+13126603535">312-660-3535</a><br>
><br>
> Cell: <a href="tel:330-807-1043" value="+13308071043">330-807-1043</a><br>
><br>
> Web: <a href="http://crunchtools.com" rel="noreferrer" target="_blank">http://crunchtools.com</a><br>
><br>
> When should you split your application into multiple containers?<br>
> <a href="http://red.ht/22xKw9i" rel="noreferrer" target="_blank">http://red.ht/22xKw9i</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Diógenes G. Rettori<div>Openshift Product Manager</div><div>@rettori</div></div></div>
</div></div>