...

Base image adoption is  not vetted by ONAP’s security subcommittee. We are missing the opportunity to adopt, in a scalable manner, security best practices and guidelines across all base images.

What if the Security SubCommittee sub-committee had the opportunity to review and provide input on the common images we adopt? We will be able to adopt, in a scalable manner, their recommendations and enable security best practices and guidelines across all base images.

...

Like any other open source project, we can’t control upstream projects. Updates are released that Upstream project updates have proven to disrupt our work and caused us pain. Case in point, the change in the nss library that affected a few ONAP projects. We can’t prevent , these events but we can acknowledge, these events and certainly take actions to mitigate risks.What if could store, share, update, analyze and secure the OS distribution and packages in a way that it offers projects stability during each development cycletheir impact.

Figure 2 shows how ONAP projects tend to use ONAP's most popular distributions for base images. It is clear that ONAP projects favor alpine for their development base images. "Development base images" are use those used to develop ONAP services (e.g. python, java, node0.  The most popular distributions for base imagesnode).

What if could store, share, update, analyze and secure a common alpine distribution? This approach will ensure both re-use and stability during each development cycle.

Proposed Solution

Common OS Repository

A practical way to achieve stability is to install a local OS repository, such as an Alpine distribution repository, that . This repository (i.e. mirror) can be easily installed, locked and stabilized for the duration of a an ONAP release.

Figure 2: Percentage of Linux distribution usage for ONAP development images

...

Other than creating production-ready images, there are benefits to development in being able to easily replace the base image.

For example, it's possible to create a development (i.e. debuggable) version of the base image, with default configuration enabling more logging, instrumentation, network capturing services, etc.  It also makes it more easy easier to test the impact of an upgrade of a library across all of ONAP, for example moving from JDK 11 to JDK 12.

Common base image repository

A practical way to enable the use of common base images is to setup a common repository.

What would be the content of the repository? Besides the basic Alpine Linux distribution, its libraries and packages, the repository will contain base image abstractions or aliases.

Base Image Abstractions

Image abstractions can be used to increase re-usability and enhance stability.

For example, for ONAP Python projects the "FROM" statement could point to:

...

All Java 8 components in ONAP would be doing the same, so any consumer would only ever download that JDK once. It would be relatively easy to swap out that JDK. For example, a consumer might want to use a security-patched, custom-built version of OpenJDK and not wait for ONAP to make a new release. So, they would first rebuild the "onap/base-java-8" image, and then trigger a rebuild of all derived ONAP packages. Assuming integration tests are successful, they are good to go.

Dependencies

One potential challenge would be where to put dependencies: there might be a concern that various little dependencies would be pushed into "onap/base" and that it would become bloated.

...

Base Image Life Cycle

It is relatively simple easy to adopt introduce a new base image images to ONAP today. The On the other hand, the process of maintaining those images and deciding when it they no longer serves its serve their purpose is not consistent across ONAP projects.

A well-known, predictable image life cycle will help implement a transparent process to adopt common base images. To accomplish this goal, Figure 3 shows the proposed life cycle for ONAP’s common base images.

Figure 3: Life Cycle of ONAP's Common Base Images

...

Today, developers and teams choose , separately --independently for the most part, -- their base images. It all makes sense because developers are the ones who know what is best for their projects. We are clearly confronted with a case of local optimization.

What if we came together as a community (PTLs, TSC, Security SubcommitteeSub-committee), shared our experienceexperiences, reduced duplication and minimize minimized the effort to maintain common components.

At the same time, what if we gave all stakeholders a voice in deciding what images and versions we should adapt for the benefit of everybody.?

Process and Stakeholders

Initially, PTLs and TSC members will review and adopt the current ONAP Normative Images maintained by the CIA Project as the seed of the common base images list.

...

Initial setup

As the first step of the proposed approach, the Linux Foundation infrastructure team sets up a stable repository of base images and libraries to hold and serve the images listed above. These are current set of ONAP Normative Container Base Images.  This is a one-time events event expected to take place before El Alto’s M1. After this

Stable process

After the initial setup, the process enters into a cycle that follows the cadence of ONAP releases as follows.:

...

The proposed approach to this project initiative is incremental and iterative as shown on the roadmap below.

...