...
- 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)
- OOM: helm charts?
- There is no transparency whether uses cases are relying on unmaintained software modules (repositories)
Proposal
The information about software modules (repositories) included in an ONAP release must be managed ...
...