Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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:

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)
    • conclusion:
  • 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
    • next step:
  • No labels