Versions Compared

Old Version 48

changes.mady.by.user Byung-Woo Jun

Saved on

compared with

New Version Current

changes.mady.by.user Byung-Woo Jun

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Key Contacts - Byung-Woo Jun  (Ericsson)


Note: The ONAP Streamlining - The Process has been approved by ONAP TSC


ONAP Benefits to the Industry

Contribution - Great Accomplishments!

...

ONAP Deployment Dependencies (by Andreas Geissler)

See ONAP deployment dependenciesevolution 


ONAP Helm Charts Dependencies (by Andreas Geissler)

...

  • ONAP supports clustering components by use cases:
    • Selection of the best components for a particular task in systems
    • Responsive integration and delivery
    • ONAP still can provide reference automation for coordination
  • ONAP E2E integration testing can be performed for code quality.
  • Focused Integration testing can be performed, based on use cases.
  • Additional analysis will be provided as needed.


Release Management

...

Tasks 

  • Marketing version, Montreal, will be scheduled as the previous releases.
  • Setting release schedule plans for Montreal
  • The Marketing version will be used as the Major version by ONAP projects
  • PTLs decide the minor and patch versions, based on their project release cycles and share the project versioning with TSC
    • Provide each component release flexibility and evolution
  • Integration & Pair-wise testing
  • Integration testing will continue to increase ONAP project overall qualities
  • Pair-wise testing will continue but it will be based on use cases
  • Project testing will be performed by each project team
  • For Montreal, security scanning will continue as before

  • Based on feedback during the Montreal, the release plan can be revisited

...

  • Each PTL determines their project agile cycle(s) based their features
  • PTLs/Feature owners coordinate with ARCCOM/REQCOM/SECCOM/TSC for the feature review and approval per agile iteration
  • PTLs/Feature owners may work with OOM, INT and DOC for build, testing and documentation, as needed
    • project release specific documentation should be handled in a automated fashion (e.g., scripts; PTLs create the release-specific rst and scripts put the rst contents into RTD)
  • Each agile iteration/sprint is reviewed and critiqued by the project team (and ARCCOM/REQCOM/SECCOM/INT/TSC as needed…) and is used to determine what the next step (PTL decides it) until RC
    • e.g., priorities, guidance, standards, security…
  • After Montreal, we may want to revisit the Marketing release RC and Sign off

...

References

...