...
Amy Zwarico Pawel Pawlak Eric Debeau Cedric Ollivier Andreas Geissler Timo Perala Sylvain Desbureaux
Kenny Paul David McBride Catherine Lefevre
...
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
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.Knowledge about:
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. / 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.
- 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 deployed '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 and /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 (rel mgr, projects, oom, sec, doc, ...)
- 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 a 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 (relmgr, oom, sec, doc) 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
...
...
- 211128.xlsx
- conf.py (istanbul) showing the current situation for documentation: