| Table of Contents |
|---|
TL;DR
Today, ONAP is dealing with uses a number of different container base images , and different versions of the same base images, . At the same time base images are not vetted by the security subcommittee. We For example, we currently use 5 different versions of node, 9 different versions of openjdk and 13 different versions of Python across ONAP projects.
This approach has led to duplication of efforts and inefficiencies, inefficiencies such as resource consumption, large footprint and long build times. Also, teams , experience unnecessary pain when unexpected changes occur in upstream projects.
...
- Proposed
- Under review
- Adopted
- Maintained
- Retired
PTLs, the Security Committee Sub-committee and the TSC will drive images through this life cycle.
Images will remain stable during each development cycle and are only subject to change will only be updated in-between development cycles.
The ONAP community already came together and made great progress in reducing the image footprint. A lot of people contributed to make that a reality.
We still have work to do. Now we are presented with This proposal gives us an opportunity to work together to uncover, and remove, efficiencies and to introduce time-saving strategies to help ease everybody’s pains.
...
These problems are caused in part because everyone is spread too thin. Getting more contributors is not always feasible. We have a lot of moving parts to deal with. On top of that, we need to release on time while at the same time stabilize new features and reducing reduce technical debt.
For example, the community came together and made great progress in reducing the footprint. A lot of people contributed to make that a reality. We still have work to do. Now we are presented with We have an opportunity to work together to uncover, and remove, efficiencies and introduce time-saving strategies to help ease everybody’s pains.
What if we could mitigate these problems by adopting common base images with a clear and predictable life cycle? What if these common base images were re-usable across a large number of ONAP projects?
Furthermore what if these common images were vetted by the community in terms of their footprint, stability and security?
...
Figure 1 shows how ONAP uses a number of different base images for similar purposes and different versions of the same base images.
We For example, we currently use 5 different versions of node, 9 different versions of openjdk and 13 different versions of Python across ONAP projects. There is very little re-use and the commonalities across projects are not being exploited.
It is clear that there is significant commonality across ONAP base imagesprojects. What if we benefited from it that commonality by adopting a set of common base images that were shared across ONAP projects? These common images will increase re-use. Teams and PTLs will share stable base images across projects. Developers will have a common starting point for their services. Developers Most importantly, developers will have one less thing to maintain and worry about.
...
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 cycle.
Figure 2 shows how ONAP projects tend to use their impact.
Figure 2 shows 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.:
| Milestone | PTL | SecCom | TSC | CIA | Linux Foundation Infrastructure Team |
|---|---|---|---|---|---|
In between releases (Before M1) | -Submits Add, Update, Remove request via JIRA issues. -Review and vote on proposed changes. | -Reviews and votes on proposed changes. -Proposes changes and adoption of security best practices concerning container images. | -Reviews and provides input on state of common images to seek alignment with ONAP-wide initiatives. | -Proposes applicable best practices. -Facilitates image life cycle change requests. | |
| M1 | -Finalize common image updates via consensus. -Votes allocated as follows: One PTL one vote. | -Approves and socializes changes to common images repo. | -Coordinates with LFN infrastructure team via helpdesk tickets. | -Updates and locks repo. | |
| M2-Release | -Adopts common base images for development. | -Monitors ONAP common images. -Requests updates to deal with critical security issues. | -Facilitates emergency image life cycle change requests. -Coordinates with LFN infrastructure team via helpdesk tickets. | -Applies emergency repo updates. |
...
The proposed approach to this project initiative is incremental and iterative as shown on the roadmap below.
...
| Roadmap Planner | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|