Increased transparency on software modules included in an ONAP release

Owned by Thomas Kulik
Last updated: Jan 10, 2022
3 min read

*** PROPOSAL FOR DISCUSSION ***

@Amy Zwarico @Paweł Pawlak @Eric Debeau @Cédric Ollivier @Andreas Geißler @Timo Perala  @Sylvain Desbureaux 

@Kenny Paul @David McBride @cl664y@att.com 

Targets

ONAP must not depend on unmaintained software modules / projects.

Increase transparency on software modules (repositories) included in an ONAP release to enable effective and efficient ...

  • security management

  • release management

  • documentation management

Provide reliable information for all stakeholder (rel mgr, projects, oom, sec, doc) ...

  • which software module (repository) is included (was used to build the docker container)

  • which version of the software module is included (was used to build the docker container)

Improve the lifecycle management of software modules/projects.

Provide transparent and reliable knowledge about the ...

  • relationship between ONAP Release → Docker Container & Version → Repository & Version → Project

    • (relationship currently missing is: Docker Container & Version → Repository & Version ; see also here)

  • dependencies (deploy time & runtime) among ONAP projects

  • dependencies (runtime) between ONAP projects and use cases

  • current lifecycle state of ONAP projects and repositories (incl. optimized maintenance of this information)

Enable a reliable and prompt decision making in case of unmaintained projects/repos.

Current Situation

  • A deployable ONAP release consists of 'maintained' an 'unmaintained' software modules (used to build the docker container).

  • Only 'projects' are managed in the release process

  • But a 'project' consists of 1-n repositories. Repositories are not managed in the release process.

    • Question: If a project is (un)maintained, are all repositories (un)maintained?

  • Only 'maintained' projects are managed in the release process.

  • But "unmaintained" software modules (docker container) are added to the list of deployed software modules in the end of the release process (oom)

  • Unmaintained, but 'participating' projects (not repositories!) of the 'Istanbul' release are:

    • Application Authorization Framework AAF

    • Application Controller APPC

    • External API

    • External System Register ESR

    • Logging

    • MUSIC

    • Portal

    • Virtual Infrastructure Deployment VID

  • The management of 'release participation' ...

    • is limited (projects managed, not repositories)

    • has distributed responsibilities (relmgr, oom, sec, doc)

    • and is not synced and done in a collaborative, end-to-end manner

  • Information about the lifecycle state of projects/repositories and their release participation is distributed, manually maintained and not in sync, e.g.

    • GIT: repository state (active | read only; Kenny? LFIT?)

    • INFO.YAML: project state (inherited to every repo of the project; project lead)

    • WIKI: release participation (release manager)

    • WIKI: project lifecycle state (Kenny)

    • WIKI: documentation tracking per release (doc team)

    • WIKI: security vulnerabilities / package updated (sec team)

    • WIKI: Arc Subcommittee / ONAP Architecture Diagram

    • RTD: Interactive ONAP Architecture Diagram

    • OOM: helm charts?

    • Jenkins Jobs?

  • There is no transparency whether use cases depend on unmaintained software modules (repositories)

Proposal

The information about software modules included in an ONAP release must be managed ...

  • by the release manager (responsible) and stakeholder (contributing)

  • on repository level

  • from the start of the release process (planning phase)

  • to the end of the release process

    • building the deployable release

    • building the release specific documentation

  • consistently (one single source) for all stakeholder

  • with a high grade of automation

Dependencies between ONAP projects and use cases must be managed ...

  • by the Architecture Subcommittee (incl. continuous documentation) together with the TSC (incl. the decision how to continue with an unmaintained project)

  • on project level

To finally participate in an ONAP release, a software module ...

  • must be in the 'maintained' state

  • must have created a release branch

  • must have updated their documentation to reflect the current state of development

  • must have up-to-date release notes (on sub-project level or in the main project)

Stakeholders are only using/managing maintained software components/projects.

Use cases are based only on functionality provided by maintained projects/repositories.

The release process ensures the compliance of the above topics and provides appropriate means to check and react in a timely manner. 

Additional Information