On 05/15/2017 09:09 AM, Scott McCarty wrote: > > > On 05/15/2017 09:06 AM, Dusty Mabe wrote: >> >> On 05/15/2017 08:59 AM, Scott McCarty wrote: >>> >>> On 05/15/2017 08:28 AM, Dusty Mabe wrote: >>>> I would encourage you to make this image "timeless". For the lab we did at >>>> summit someone could theoretically download the qcow2 years from now and >>>> still >>>> run through the entire lab. We baked all of the container images we needed >>>> as >>>> well as all rpms we needed for 'builds' into the image and also tested it >>>> completely offline. >>> Yeah, I really, really like this idea. I need to figure out how to get >>> the RPMs baked in. I am quickly realizing that I need to have a Red Hat >>> downstream version of this lab and an upstream version because the RPMs >>> for the rhel-tools image aren't redistribute-able :-( without breaking >>> the RHEL legal rules. >>> >>> What did you use to cache the RPMs? Some kind of proxy? >> I initially set up a squid proxy and ran through the entire lab with the >> container builds pointing to the squid proxy. Then I just used the logs >> from the squid proxy to grab the NVRA of the rpms we needed and then used >> yumdownloader (or dnf download in your case) to get them. >> >> I wouldn't bother trying to pull the actual rpms out of the squid proxy >> cache. It's in some format that is optimized for fast access and not trivial >> to get the actual files back out of it. > > Intteresting. I I am thinking maybe, I would just leave squid running on > Atomic Host :-) I have automated builds in OpenShift happening, so there > is no easy way to bind mount the RPMs in to the containers at build > (that I know of).
Maybe leaving squid running on atomic host would work, but I can't guarantee that (also not sure how long before the cache cleans up the content). > > How did you configure the proxy in the containers? Just drop in a > yum.repos file? yeah. I also think that you might be able to use HTTP_PROXY env vars. >> >>>> Also 'virt-sparsify --compress' is your friend. >>>> >>>> >>>> >>>>> [1]: https://github.com/fatherlinux/container-internals-lab >>>>> >>>>> >>>>> Best Regards >>>>> Scott M >>>>> >>>>> >
