Versions Compared

Key

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

...

  • 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
  • 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 Deployment

Image Removed


Current Helm Deployment

for the current ONAp Helm deployment hierarchy, see the ONAP deployment wiki pages (<see, ONAP deployment by Andreas Geissler), ONAP Deployment#CurrentHelmDeployment > .


ONAP Component Autonomous and Interface Abstraction

...