...
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
- ONAP must not depend on unmaintained software modules / projects release management
- documentation management
...
Improve the lifecycle management of software modules/projects.
Transparent Provide transparent and reliable knowledge about the relationship of ONAP ...
- 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 uses use cases are based depend on unmaintained software modules (repositories)
...
The information about software modules (repositories) 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 ...
...
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
...
- : onap_tables_211128.xlsx
- conf.py (istanbul) showing the current situation for documentation: