*** PROPOSAL FOR DISCUSSION ***
Amy Zwarico Pawel Pawlak Eric Debeau Cedric Ollivier Andreas Geissler Timo Perala Sylvain Desbureaux
Kenny Paul David McBride Catherine Lefevre
Target
Increase transparency on software modules (repositories) included in an ONAP release to enable effective and efficient ...
- security management
ONAP must not depend on unmaintained software modules / projects
- 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.
Transparent and reliable knowledge about the relationship of ONAP Release → Docker Container & Version → Repository & Version → Project
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.
- 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?
- There is no transparency whether use cases depend on unmaintained software modules (repositories)
Proposal
The information about software modules (repositories) included in an ONAP release must be managed ...
- by the release manager (responsible) and stakeholder (contributing)
- 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
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
Excel Spreadsheet
conf.py (istanbul) showing the current situation for documentation