*** PROPOSAL FOR DISCUSSION ***
...
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 ...
...
Provide reliable information for an ONAP release 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 partizipationparticipation' ...
- 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 partizipation 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 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: