On Fri, Aug 10, 2018 at 05:17 AM, Tal Liron wrote: Regarding choice of base image:
Alpine Linux is prized for container images because it's a very minimal OS, so the image size is tiny in comparison to other OS images and there is no "bloat" with unused software packages. This may also help with getting it passed by each company's security scans. Even if larger base images are chosen, the use of overlay file systems means that base images are immutable and shared, with local file changes performed in a different layer and stored separately. That means the "many gigabytes of storage" is much less of a problem than it appears (the commands that show the sizes of images do not account for sharing of base layers) and base layers only need to be downloaded once. Careful design of the file system layering can make the size problem easily manageable. If the projects are commonly adding extra software to base images, then those could/should be re-based from new images that have those tools already baked in (again helping with the sharing of layers). If each participating companies can scan/approve the base images, then maybe this problem just goes away! Regarding repositories: Doesn't ONAP already use https://nexus3.onap.org/ as the common repository for Docker images? Regarding uniformity in images: Since we know ONAP is intended to be customised by each company using it, strict uniformity isn't needed or even a goal. The assertion that "users can easily swap" may be a little too glib because we know that substituting "equivalent" software doesn't always work as expected. It needs testing to confirm. Also, who is doing support for untested combinations? So, the projects should probably commit to some range of testing using "equivalent" combinations of OS/JDK/DB/libraries/etc tools, so that companies can rest assured that it should work for them. It would be great if an "ONAP" base image is one of those testing targets, as it could prove that it's easy to converge on a common base image. This could also work for converging versions of libraries in use (e.g. Jackson - 24 versions used in 21 projects !?!). Jenkins should be able to handle it, as long as there is enough IT infrastructure to run all the extra jobs. Regarding using Buildah: Ironically, part of the solution is to pull yet another software package from the internet! >From https://www.projectatomic.io/blog/2017/06/introducing-buildah/ it looks >good for build-time environment since it doesn't require installation or >running of the docker daemons. Buildah is not the only choice in this space, >but it is backed by RedHat. I would like to be able to easily pull in the entire ONAP code base, build every component and locally deploy a fully functional ONAP system with working default configurations and seed data. It is currently a pipe dream (it's not so easy at the moment). Keong PS: Baseless conspiracy theory: The ONAP project name for Docker/OCI is "CIA" and according to Wikipedia "In April 2014, it was revealed that the C.I.A.'s investment arm In-Q-Tel was a large investor in Docker". Coincidence!?! -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11806): https://lists.onap.org/g/onap-discuss/message/11806 Mute This Topic: https://lists.onap.org/mt/24242182/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
