Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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.

...