Agenda:

Antitrust Policy Statement:  Meetings of the ONAP Project involve participation by industry competitors,  and it is the intention of the Project to conduct all of its activities in accordance  with applicable antitrust and competition laws. It is therefore extremely  important that attendees adhere to meeting agendas, and be aware of and not 
participate in any activities that are prohibited under applicable U.S. state,  federal or foreign antitrust and competition laws. Examples of types of actions  that are prohibited at ONAP Project meetings and in connection with ONAP  Project activities are described in the The Linux Foundation Antitrust Policy. If  you have questions about these matters, please contact your company  counsel or Andrew Updegrove, of the firm of Gesmer Updegrove LLP, which  provides legal counsel to The Linux Foundation.
Linux Foundation Antitrust Policy:  https://www.linuxfoundation.org/antitrust-policy

  1. Assemble/Welcome (5 min) 


#

Objective

How Achieved

Participant Preparation required

Action items out

2Review JIRA Backlog. Participants should be comfortable that they understand the backlog of tasks for our project ( 15 min)

Walk through the JIRA backlog to check for completeness

on VNF RQTs

https://jira.onap.org/browse/VNFRQTS-134

I am not sure to understand how this is impacting Amsterdam Release?

review:

vnfrqts bugs


3Develop Beijing Release project plan for VNFRQTS . Participants should be comfortable with an achievable development scope ( 30 min)

VNF Use cases ?

VNF Test Case Descriptions?

vnfrqts Beijing Release Plan


propose a minimal "getting started" sprint scope.

ensure that suitable JIRA tasks are already in place to support this scope.

review:

vnfrqts Project charter

vnfrqts Epics

vnfrqts User Stories

Create / edit 

vnfrqts Epics

vnfrqts User Stories

vnfrqts Beijing Release Plan

   4. Any other Business? (5 min) 


meeting record 



  • No labels

2 Comments

  1. wenyao guan

    Please discussing the modified content of the Guidelines document:

    Part I : Purpose and Scope modification

    Purpose
    • This document focuses on setting and evolving VNF standards that will facilitate industry discussion, participation, alignment and evolution towards comprehensive and actionable VNF best practices and standard interface.
    • The goal is to accelerate adoption of VNF best practices which will increase innovation, minimize customization needed to onboard VNFs as well as reduce implementation complexity, time and cost for all impacted stakeholders.
    • The intent is do drive harmonization of VNFs across VNF providers, Network Cloud Service providers (NCSPs) and the overall Network Function Virtualization (NFV) ecosystem by providing both long term vision as well as short term focus and clarity.

    Scope
    • The audience for this document are VNF providers, NCSPs and other interested 3rd parties who need to know the design, build and lifecycle management requirements for VNFs to be compliant with ONAP.
    • These guidelines describe VNF environment and provide an overview of what the VNF developer needs to know to operate and be compliant with ONAP.
    • These guidelines are applicable to the Amsterdam release of ONAP.
    • Scope of the ONAP versions/release and future functionality

    • These guidelines contains high level expectations and references to specific requirements documentation for VNFs which are applicable to the Amsterdam release of ONAP.
    • Part of the guidelines also contains visionary recommendations for future functionality that could be desirable for ONAP future releases.

    • Conformance requirements are in the requirements document.


    Part II

    VNFs updates and upgrades within ONAP

    ONAP will orchestrate updates and upgrades of VNFs. The One target
    method for updates and upgrades is to onboard and validate the new
    version, then build a new instance with the new version of software,
    transfer traffic to that instance and kill the old instance. There
    should be no need for the VNF or its components to provide an
    update/upgrade mechanism.


    Part III

    Guest Operating Systems

    VNFs should use the NCSP’s standard set of OS images to enable compliance with security, audit, regulatory and other needs.


    Modification option 1:

    NCSPs could require that VNFs shoulduse the NCSP’s standard set of OS images to enable compliance with security, audit, regulatory and other needs.


    Modification option 2:

    It could be desirable for VNFs to be able to run on the GuestOS recommended by NCSPs to enable the compliance with security, audit, regulatory and other needs.



  2. Steven Wright

    All components in ONAP should be virtualized, preferably with support for both virtual machines and containers. All components should be software-based with no requirement on a specific hardware platform.

    To enable the compliance with security, audit, regulatory and other needs, NCSPs may operate a limited set of  guest OS and CPU architectures and families,  virtual machines, etc. 

    VNFCs should be agnostic to the details of the Network Cloud (such as hardware, host OS, Hypervisor or container technology) and must run on the Network Cloud with acknowledgement to the paradigm that the Network Cloud will continue to rapidly evolve and the underlying components of the platform will change regularly.