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
- Assemble/Welcome (5 min)
# | Objective | How Achieved | Participant Preparation required | Action items out |
---|---|---|---|---|
2 | Review JIRA Backlog. Participants should be comfortable that they understand the backlog of tasks for our project ( 5 min) | Walk through the JIRA backlog to check for completeness | review: | |
3 | Develop Beijing definition. Participants should be comfortable with an achievable development sprint scope ( 30 min) | walk through Beijing EPICs , User Stories | propose a minimal "getting started" sprint scope. ensure that suitable JIRA tasks are already in place to support this scope. review: R2 Use cases - VNF Scaleout | Create / edit for the function requirements for Beijing: HPA-Herb Change Management - Scott Scaling ( auto & Manual) - Scott PNF - Marge Network Slicing - John Data - John Path - Steve defer to Casablanca the following EPICs: |
4 | Relationships with other projects in Beijing? (10 min) | review project handoffs | review handoffs with DOCS VVP VNF SDK Modelling others? | create any necessary User Stories Steve to Check with Andy Mayer where is latest list of VNF information elements? |
5. Any other Business? (5 min)
11 Comments
Herb Patten
Update on HPA:
Here is the most recent information on HPA requirements:
https://wiki.onap.org/display/DW/Hardware+Platform+Enablement+In+ONAP
VNFRQTS would document those HPA requirements for a VNF from a generic perspective. I presume we'll feed them back to VNFRQTS from VNF SDK (and other impacted projects implemented the HPA functional requirement).
Alexander Vul
Hi all,
As part of R2, we would need to provide guidance for VNF developers with respect to use of TOSCA based VNF descriptor templates, as well as specification of hardware platform capability requirements as part of the template. The modeling subcommittee is in the process of defining the VNFD template for developers. The HPA project will define a set of initial HPA capabilities for support in R2.
Kind regards,
Alex Vul, Intel
HPA FR Owner
Steven Wright
at: Beijing Functional Requirements for TSC Approval is a Jan 11th deck ONAP Beijing functional requirements.pptx which has a list of the contact people for each of the proposed functional requirements for Beijing release
Steven Wright
I created 2 top level JIRA Epics to cover the Bejing scope:
VNF requirements project improvements to support ONAP Platform Maturity initiatives
VNF Requirements improvements to support Beijing Functional Requirements
I suspect that vnfrqts will need some additional user stories under vnfrqts-158 to support the VNF impacts of new functions proposed.
Marge Hillis
I analyzed the 5G sub-use case for PNF instantiation. This Use Case does not create additional requirements on the VNF. However there is a requirement on the PNF to generate a VES Event Message to DCAE to register once Boot Strap Software capable of talking to ONAP has been downloaded to the PNF. That message is needed to trigger other activities in ONAP.
I think we should open a JIRA Story to determine how PNF requirements are captured. I have not seen PNF requirements in the READ THE DOCs–maybe I am missing them. Not all VNF requirements really apply to PNFs like scale in scale out–the PNF is a physical entity in a physical location. Some requirements for a VNF seem to be applicable to a PNF such as sending alarm events and how those should look etc. It seems like one could create a separate set of documents for PNFs or one could create a table (like for the VNF management requirements where one could indicate if the requirement was applicable to a VNF a PNF so we would not have to worry about keeping requirements that we would want to be the same in synch–both options have pros and cons.
Steven Wright
Thanks Marge!
I've created a User Story VNFRQTS-160 PNF requirements
and an initial task VNFRQTS-161 to update the document outline structure to support PNFs
John Quilty
I have analysed the Network slicing use case for Beijing. The use case does not generate any VNF requirements. There is little Slice awareness at the VNF layer (aside from the DECOR slice selection mechanism defined in 3GPP). The slice awareness is in ONAP with any configuration sent over the standard OAM Configuration interface. The creation of slice related analytics will be built in DCAE, the VNF will supply the performance data as normal.
Steven Wright
so I assume no new user story required here.
John Quilty
In relation to Data collection there are two detailed issues not picked up yet
Are we going to expand VNF requirements to handle PNF requirements for ONAP, it so we need an EPIC on PNF Data collection
Steven Wright
We have a some existing requirements for DCAE support and an existing JIRA task related to DCAE:
e.g. VNFRQTS-13
Do we need a new JIRA task in VNFRQTS? or are you looking for new functionality in DCAE?
Steven Wright
on Path
I have emailed the feature leads, but received no reply.
most of the other ONAP projects have marked this as either NA or NO (SDC) .
I marked this as an NA for the VNFRQTS project. hence no new JIRA task is planned for this is Beijing release.