...
- 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://wiki.onap.org/display/DW/Proposal%3A+Break+ONAP%27s+monolithic+version+schema
- Currently, all the ONAP component helm charts have the same version number (e.g., 13.0.0). for a start,
- Helm charts dependencies need to be analyzed (by Andreas Geissler), see https://wiki.onap.org/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.
ONAP Component Individual Storage and Deployment
The following diagram depicts the CI/CD pipeline and deployment of ONAP.
- Deployment options: individual components vs. ONAP centralized
- See the current Helm deployment (Andreas Geissler created), https://wiki.onap.org/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
Current Helm Deployment
Separation of ONAP Components
The reference OOM wiki page will describe how to separate ONAP components, (Montreal) Separation of ONAP components
In there, the following main topics are described.
- Helm chart separation, versioning concept and release management
- Deployment options (ONAP centralized vs. individual components)
ONAP Deployment Dependencies (by Andreas Geissler)
See ONAP deployment dependencies
ONAP Helm Charts Dependencies (by Andreas Geissler)
See ONAP Helm chart dependencies
Break ONAP Monolithic Version Schema (by Florian Bachmann)
See Proposal: Break ONAP's monolithic version schemafor the current ONAp Helm deployment hierarchy, see the ONAP deployment wiki pages (by Andreas Geissler), ONAP Deployment#CurrentHelmDeployment .
ONAP Component Autonomous and Interface Abstraction
- ONAP component functions should be designed/used for/by not only ONAP but also non-ONAP.
- ONAP component functions can be substituted and/or extended by vendors/operators
- Component dependencies and couplings to other ONAP components should be removed.
- Those dependencies and couplings could be both syntactic and semantic
- Intra-ONAP component interfaces and communications should not be ONAP-specific.
- Aligning with standards where possible (e.g., ETSI NFV MANO, ASD, 3GPP SA5…) should be global requirements
- If there must be a deviation, that can be done in an extensible way that enables the standard-based approach
- The exposed service interfaces should be for both ONAP and non-ONAP; promote ONAP component interfaces as LFN de facto standards
- If exposed service interfaces conform to industry standards (e.g., ETSI SOL005, ETSI SOL003, 3GPP SA5), the interactions between the service provider and consumer would be simplified (e.g., VFC case in this diagram)
- The For now, the service consumers can use “adapters” which choose a desired service interface
...
- ONAP components are protected by Ingress Controller, Keycloak (IdAM) and Istio (Service Mesh), with AuthN/Authz, intra-secure communications, external-secure communications.
- ONAP components themselves do not have their own/ proprietary protection any longer (e.g., removal of HTTP Basic Authentication and HTTPs).
- Current OOM-provided security support as described above will be provided as ONAP reference security mechanism.
- It is assumed that vendors/operators support industry de facto security mechanism like ONAP security and imported ONAP components are protected by the security mechanism.
- ONAP will provide documentation of security architecture, global requirements and best practices, informing how to protect/secure selected ONAP components.
- For secure external communications, Ingress Controller, aouth2-proxy and IdAM are used
- For intra-secure communications, Istio is be used with Cert-Manager and policies
- For user authentication and authorization, KeyCloak is used, with SSO support and OAuth2-based token generation and validation
ONAP Component Code Security Analysis
Each ONAP component needs to meet code security practices and certifications that are defined by SECCOM. There would be no direct impact for ONAP Streamlining.
Additional analysis will be provided as needed.
ONAP Component Logging Analysis
- 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://wiki.onap.org/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
...
- 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 - TBD...
...
- ONAP Streamlining LFN D&TF June 2023 presentation, https://wiki.lfnetworking.org/download/attachments/82906137/ONAP%20-%20Streamlining%20the%20process-v7.pdf?version=1&modificationDate=1686246324000&api=v2
- ONAP Deployment dependencies (by Andreas Geissler), ONAP deployment dependencies
- ONAP Helm chart dependencies (by Andreas Geissler), ONAP Helm chart dependencies
...