Here are the minutes, also on the wiki at

2016-Sep-19 Models Project Meeting #12

  *   Bryan Sullivan, AT&T
  *   Prakash Ramchandran, Huawei
  *   Artur Tyloch, Canonical
  *   Ulas Kozat, Huawei
  *   Alex Vul, Intel


  *   Status of current work
     *   Hello World on Tacker
     *   Hello World on Cloudify
  *   VNF Onboarding
  *   VES event model in YANG
  *   Goals thru 2016
     *   Demo at OpenStack Barcelona
     *   Dec plugfest at U-NH
     *   Reference libraries

Minutes (feel free to add additional notes):

  *   Status of current work (Bryan)
     *   Hello World on Tacker:<>
        *   Tacker install and blueprint deployment is working reliably on Apex 
and JOID, in non-HA/no-SDN scenarios.
     *   Hello World on Cloudify:<>
        *   Cloudify-CLI test development is suspended due to apparent 
incompatibility with OpenStack Mitaka (the Cloudify OpenStack 
Plugin<> is not 
compatible with recent OpenStack releases)
        *   Cloudify-Manager test development continues. Currently the 
 is working but starting the blueprint is failing (timeout installing the 
Cloudify Agent in the VM... being investigated).
     *   VES support in blueprints
        *   A quick investigation was made into how a VNF's VDU can discover 
its Nova instance ID, so that it can attach to the VES Collector and identify 
itself thru the ID. It was found that two methods exist for this: the Nova boot 
"meta" option<> and the Nova 
option. The metadata service however does not provide the actual Nova instance 
ID (some other value is in the "instance id" field). The config-drive option 
does. See the attached 
 demo log file (which combines a demo of the Hello World Tacker test and the 
Copper<> test 
which now supports creation of the config-drive for one of the VMs).
        *   The key takeaway for the Models project on this is that it 
represents one of the things that needs to be model-able, i.e. that in some 
cases a VNF needs to know its Nova instance ID (or other metadata), and thus 
some way to indicate that the config-drive should be allocated (or the metadata 
provided through the metadata service). This need should be expressable in the 
TOSCA blueprint for a VNF.
        *   Alex questioned the approach of providing metadata of this type 
directly to VMs, and offered some other suggestions on how to achieve similar 
goals. Those discussions will continue as needed in the VES project, which is 
where modeled telemetry/closed-loop-monitoring will be addressed.
  *   VNF Onboarding (Bryan)
     *   The VNF Onboarding<> 
page on the MANO WG wiki now has a table describing a VNF lifecycle view with 
the activities related to development, onboarding, and production phases 
listed, and associated with OPNFV projects where applicable. This is a 
first-pass analysis intended to help us organize/prioritize work related to the 
Models project. Initial Models project focus has been on the production phase 
(as described there: NFVO/VNFM support for standard VNF package deployment; 
package attributes defining deployment reqs of VNF/service/end-user; VNFM 
support for VNFD lifecycle hooks; package attributes defining resource 
management reqs of VNF/service/end-user).
     *   We should have a discussion on the MANO WG call on how to organize 
further updates to this table, and link it to activity for the next level of 
analysis/prototyping. We need to do this to fulfill the intended role of the 
MANO WG in OPNFV re the higher-level roles of the Polestar WG (see 2016-Sept-15 
minutes<>) and 
  *   VES event model in YANG (Bryan)
     *   I am working on a YANG data model for VES, and will upload that to the 
VES wiki and git repo soon. The telemetry needs/capabilities of VNFs will be a 
model-able aspect that needs to be considered as part of the VNF package. This 
is the first case (in OPNFV AFAICT) for a YANG model to be part of a VNF 
blueprint (others are expected soon e.g. for application data model and 
lifecycle events). For the Models project, the issue will be how to include 
YANG data models in the VNF package, and what NFVO/VNFM functions will handle 
  *   Goals thru 2016 (Bryan)
     *   Demo at OpenStack Barcelona
        *   As a sponsor, AT&T will have a booth at OpenStack. We will demo a 
VNF running on OPNFV Colorado, and integrating with a PoC 
closed-loop-monitoring system using VES as the event stream framework. This 
demo will include a reference VNF installed via a TOSCA blueprint via Tacker or 
Cloudify (or both, if we have time).
     *   Dec plugfest at U-NH
        *   As shown at Colorado Plugfest Test 
Cases<>, the 
December plugfest will cover various reference blueprint tests with any 
VNFM/NFVO projects/vendors that want to demonstrate their compatibility with 
those reference blueprints. The blueprints will be provided in October so the 
VNFM/NFVO under test can determine whether they will be able to participate. As 
noted, the goal is not 100% compatibility verification, rather "to demonstrate 
the degree of portability, uncover issues for followup, build the library of 
tested blueprints (VNFM-specific, as needed), and overall come away with a much 
clearer assessment of VNFM product support for blueprint standards"
     *   Reference libraries
        *   These will be developed as part of the Models repo through Q4 2016. 
The goal is to establish several reference VNFs and blueprints, for use in 
plugfests and Functest.

Bryan Sullivan | AT&T

Sent: Monday, September 19, 2016 8:55 AM
Subject: [Models] 2016-Sep-19 Models Project Meeting #12 agenda<>

*         Status of current work
*         * Hello World on Tacker
*         * Hello World on Cloudify
*         VNF Onboarding
*         VES event model in YANG
*         Goals thru 2016
*         * Demo at OpenStack Barcelona
*         * Dec plugfest at U-NH
*         * Reference libraries
Bryan Sullivan | AT&T

opnfv-tech-discuss mailing list

Reply via email to