...

• OOM is not a stand-alone product under "by ONAP". It is collection of scripts for component build, configuration and deployment. Also, it configures for security such as Ingress, oauth2-proxy and Istio.

ONAP Streamlining Evolution Paths

ONAP was started as a Network Automation Platform. It provides rich e2e Service use cases and functions, but it was a big and complex network automation platform. 

ONAP is a collection of network automation functions, which provides individual component functions. To be adopted by the telecom/network industry, operators and venders, ONAP has worked on the following:

• ONAP-Specific platform services have been deprecated (MSB, DMaaP, AAF, OOF) and replaced with industry de-facto mechanisms (Service Mesh, Strimzi/Kafka, Security framework, AI/ML driven optimization).
• Interface normalization and standardization
• Individual component certification
• CD-based deployment

By leveraging ONAP individual core components, ONAP will be able to aggregate them for greater solutions.

Image Added

ONAP Component Individual Build

• Leveraging the existing LF-based CI pipeline, builds ONAP components
  • Check-in ONAP component code and triggering build processes
  • Thru the CI pipeline, each ONAP component will be built by scripts (e.g., modified OOM, or project-own scripts), along with SBOM
• Helm chart separation, versioning concept and release management
  • Currently, all the ONAP component helm charts have the same version number (e.g., 13.0.0). for a start,
    • e.g., projects with PTLs can start with 13.0.0. as the major Montreal release, and they can play with minor version(s) based on their release cycle, e.g., 13.0.1, 13.1.0… Projects without PTLs (or no improvement) will have the major Montreal version, e.g., 13.0.0
    • Other options: see, Break ONAP’s monolithic version schema (by Florian Bachmann), https://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/Proposal%3A+Break+ONAP%27s+monolithic+version+schema
• Helm charts dependencies need to be analyzed (by Andreas Geissler), see https://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/Helm+chart+dependencies
• Andreas and Florian (DT) plan to present the chart versioning
  • at OOM or ARCCOM next week…
• PTLs need to determine granularities of project function exposures since a project can have multiple sub-components
  • e.g., SO, SO-NFVO, SO-CNFM…
  • In OOM, there are flags for the sub-component installation. As a result, exposed component scopes can be adjusted, as needed.

...

• Deployment options: individual components vs. ONAP centralized
• See the current Helm deployment (Andreas Geissler created), https://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/ONAP+Deployment#ONAPDeployment-CurrentHelmDeployment
• Instead of deploying a whole onap_release thru “helm deploy”, pick up ONAP components individually from repositories by leveraging CD

...

• ONAP supports open-source and standard-based logging.
• ONAP already separates log generation from log collection / aggregation/persistence/visualization/analysis.
  • Each ONAP component handle log generation only thru STDOUT and STDERR, by following ONAP security logging fields – global requirements, https://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/Security+Logging+Fields+-+Global+Requirement
  • The log destination will be configured
  • Log collection agent(s) will be configured; ONAP reference configuration is using FluentBit as the collection agent;
    • ONAP uses a separate privileged namespace to deploy FluentBit for security reasons
    • Vendors/operators can configure it differently, based on their needs
  • Vendors/operators can realize and configure the log collection/ aggregation/persistence/visualization with their own logging ecosystem
• There will be no/minor impact on logging due to ONAP component disaggregation

...