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

Compare with Current View Page History

Version 1 Next »


Zoom Meeting Link:  https://zoom.us/j/137904496 International numbers available: https://zoom.us/zoomconference?m=mi-ad1sMLWlXByAKLio5vDnd9JYqUR_a

2019 Modeling Subcommittee Recordings


Duration 60 minutes


DurationAgenda ItemRequested byNotes / Links

START RECORDING:

 5Co-chair

Review Dublin Release models: ONAP R4+ Per-Project Models and API Specs

  • Request Resource IM help to update the table for IM content part.
  • A&AI reverse engineering effort

Release branch for Dublin has been created in Gerrit. Yang Xu will work out readthedoc and gerrit of papyrus with Kevin asap. (Update next week).

  • What is date for Dublin Info Model Freeze (Snapshot)
  • Need to take current snapshot as current release.
  • May be beneficial to start an El Alto branch at M3 or M4 in future releases. 

ONAP DDF proposal: will create wiki page for that session and coordinate modeling related topic together.

https://wiki.lfnetworking.org/display/LN/2019+June+Event+Topic+Proposals

 5Resource IM report

ONAP R4 Resource IM Call 2019-5-13

1 add the link of VES spec to IM wiki page

2 be open to ETSI NFV IFA/Sol further update

3 R5 related model addition needs to ask TSC confirmation.

 5Service IM report
 5

DM report



5VES

VES IM will continue in IM subteam of modeling subcommittee

VES requirement will be sent to VNF requirements. (change of artifact will be discussed under VNF requirement. reviewed by modeling subcommittee)

VES DM will be documented in modeling subcommittee.

Documenting VES and relationship to modeling

  • Need plan for what should be in VNF requirements 
  • Need right reference for registration of FM and PM dictionary (syntax for files)
  • Need to document approval process for VES specification?

modeling relationship with use case workBenjamin Cheung

AAI visualization / tooling distribution

Need feedback from the team on how to deliver AAI data model visualization and model-browser tools

VES Spec Documentation Proposal

  • What?
    • Document the VES specifications (event registration and listener) within the ONAP VNF Requirements.
  • Why?
    • ONAP needs to ensure that the xNF Vendor community is provided proper and consistent guidance with respect to VES.
    • VNF Requirements already document information about the listener and event registration.  Consolidating VES Specifications for each ONAP release into this documentation will allow greater reuse and eliminate some redundancy.
    • The VES specifications must be adhered to by VNF Provider regardless of whether the VNF is using Heat or TOSCA.  VNFSDK only concerns itself with TOSCA/CSAR so it’s not the most logical place for these specifications.  The ONAP VNF Requirements seems to be a more logical place for the VNF Provider to obtain this information. The VNF Requirements are now addressing PNFs that will need to apply VES as well.
    • The VES specification documents lack sufficient narrative to describe how to apply them. In addition these specifications have formatting errors that make it difficult to read.  The VNF Requirements team is well positioned to supply supplemental details, create both proper formatting and develop tooling to maximize re-use between the requirements and the modeling team.
  • How?
    • Document the VES Specifications (Listener & Registration) as part of the VNF Requirements for each ONAP release.  The VNF Requirements team will be able to clean up these documents as well.
      1. Augment VNF Requirements Monitoring & Management section to include narrative and reference to VES Event Listener and VES Event Registration.
      2. Include the VES Event Listener Specification as a document in the VNF Requirements
        1. This document describes the RESTful interface for the VES Event Listener. The VES acronym originally stood for Virtual-function Event Streaming, but VES has been generalized to support network-function event streaming, whether virtualized or not. The VES Event Listener is capable of receiving any event sent in the VES Common Event Format. The Common Event Format is expressed in JSON schema. In the Common Event Format, an event consists of a required Common Event Header block (i.e., object) accompanied by zero or more event domain blocks.
      3. Include the VES Event Registration Specification as a document in the VNF Requirements
        1. This document specifies a YAML format for the registration of VES Events. The YAML format enables both human designers and applications to parse and understand the fields that will be sent by event sources in conjunction with specific types of events, which are identified by their eventNames.
    • The Modeling Subcommittee would continue to produce VES Information Models that document the valid fields, values, etc. for the various elements that map into the VES related YAML files and APIs.
    • The VES Specifications in the VNF Requirements would provide the narrative and requirements on why and how to construct the files and events, but it would refer to the information model to re-use the model definitions which provides more granular detail on the field level
      • Note: Need to evaluate the options on how to map the information model as part of the VES Specification re-write (ex: link to, extract and embed).  We won’t want to duplicate the information.
    • Updates to the VES Specifications will be reviewed by the Modeling Subcommittee and the impacted projects (i.e. DCAE and VNF SDK).




ACTION ITEMS:






Zoom Chat Log






  • No labels