ONAP R4 Resource IM Call 2019-6-17

Owned by Xu Yang
Last updated: Jun 19, 2019 by Fei Zhang (Ericsson)
2 min read

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: