You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 28 Next »

*** PROPOSAL FOR DISCUSSION ***

Amy Zwarico Pawel Pawlak Eric Debeau Cedric Ollivier Andreas Geissler Timo Perala 

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
    • (warning) ONAP must not depend on unmaintained software modules / projects
  • release management
  • documentation management

Provide reliable information for all stakeholder ...

  • 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 deployed 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, not repositories), distributed (relmgr, oom, sec, doc) and is not 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?

Proposal

The information about software modules included in an ONAP release must be managed ...

  • 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

To 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 main project)

Stakeholders (relmgr, oom, sec, doc) are only using/managing maintained software components / projects.

The release process ensures the compliance and provides appropriate means to check and react in a timely manner. 

Additional Information

Excel Spreadsheet

onap_tables_211108_master_istanbul_updates_only.xlsx

conf.py (istanbul) showing the current situation for documentation

  • No labels