Page Comparison

...

...

...

...

...

...

General Information:

• Date and Time: 2019, June

...

• 17th, 9pm~10pm Beijing Time, 9am~10am US Eastern
• Meeting Room: https://zoom.us/j/645982535
• Meeting Recording: 
• Meeting Chat Log: 

Agenda:

• PNF software version proposal
• ETSI Feedback to ONAP Proposals

Material:

• PNF software version:
• ETSI NFV IFA011 changes response #2 to ONAP (Ref: NFVIFA(19)000486)

Minutes:

• PNF software version proposal
  • background: PNFD is introduced from Dublin, software version attribute is added by SDC and AAI team; but no support in the on-boarding model, and software version is not actually used
  • software version is necessary for PNF upgrade, trouble shooting and other management tasks
  • proposal:
    • option 1: additional non-mano artifact (e.g., pnf_software_version.yaml) in the pnf package, to identify the software version
      • no impact on specifications
    • option 2: addtional property in PNFD
      • simple change, align with VNFD
  • option 1 is preferred by the proposer at the time being, but can accept both solutions
  • discussion:
    • from IM perspective, what would be going to the PNF information model?
      • Kevin: from consistency point of view, could use the same approach as for VNF (option 2)
      • Thinh: ONAP and ETSI treat PNF differently, ETSI consider PNF as black box; option 1 is the right approach
    • why need to provide software version information, if we do not touch PNF software image w.r.t PNF package?
    • is it related to 3GPP spec?
      • 3GPP has specified information about software version (in runtime)
    • seems option 1 is preferred
      • continue work on updating the non-MANO artifact registry, related wiki page (ONAP Non-MANO Artifacts Set Identifiers) and DM/IM
• ETSI Feedback to ONAP Proposals
  • for watchdog:
    • no volunteer, propose to postpone
  • for vmBootupTimeout:
    • suggest to clarify the meaning of "VM ready", "VNF boot up" and relationship with VNF instance status