Page History

Agenda Topics:

SO Honolulu release.

• SO Sub-Component Module Refactoring
• Image Added
  • Seshu proposed the above SO component refactoring architecture at the ONAP Architecture sub-committee on January 12th 2021
  • The SO team discussed how to achieve this during Honolulu
  • Two steps are identified:
    • 1st steps:
      • Separate the components on needed basis from the SO Core components
      • for the components on need basis, we will have:
        • a separate project per component
        • a separate repo per component
        • a separate / independent Jenkins jobs per component
      • The Ericsson team volunteered for ETSI NFVO, SOL003 Adapter and SO Monitoring/Maintenance to achieve the 1st steps
      • Other ONAP participating companies handle other optional sub-component refactoring
      • CNFO would be a good example, according to Seshu
    • 2nd steps:
      • Once the core components and optional components are ready (i.e., successfully crated projects, repos, Jenkins, build), those components need to be integrated into SO
      • Currently, we are going to use OOM
      • Seshu is looking for its volunteers
      • The team expects Seshu to create Epic(s) for this (including the 1st steps) with high-level description / design, the participating companies will add their design into the Epics and create user stories
      • Then, the team will have a review meeting, with additional input from the OOM team
      • Then, the team will decide who is doing what for the 2nd steps

• Jira
  server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-3432

   (SO does not update ipv4-oam-address in AAI)
  • Konrad Bańka , could you please add more details here?
  • Sure, so briefly (ticket description has more in-depth status) we have custom automated test running simple VNF (1 vf-module, 1 vserver) LCM using Macro flow and some runtime verification of VM behavior. This VNF is tested on a daily basis on Frankfurt OOM and till today works correctly. It, however, doesn't work on Guilin OOM-deployed ONAP. In that case, our instantiation succeeds, but during it, VNF's IP address is no longer visible in AAI after instantiation. VNF's CSAR didn't change between those two branches and in both cases Heat Template contains relevant "output" section to provide relevant VNF's IP. As far as I remember BPMN logs in Frankfurt scenario logged two AAI requests about generic-vnf - POST (or PUT?) and PATCH, however in Guilin case, only first of these two is present. If you need any further description please take a look into ticket or ask there so we can provide any input that can be valuable for reproducing/fixing this. We will attach BPMN/Openstack Adapter logs today/tomorrow as said during the call. I think this issue should impact every SO-managed VNF that utilizes IP retrieval after vf-module instantiation, so it should be fixed in Guilin Maintenance release

• Jira
  server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-3468

   (Socket Timeout (Read Timeout) issue in DoCreateResourcesV3 for E2E flow in 1.7.10)
  • Xin Miao  brought up this issue off-line. Seshu Kumar Mudiganti , could you please take a look at this and advise? 

H release:

Image Added PDF

Project Status in Honolulu Release

Honolulu Impact View per Component

New:

H release M1 Criteria