Hi all, An update on this request. So far I've heard from the Tacker team that they can support the VNF Portability testing remotely. I want to be sure though that we have critical mass and the ability to spend time discussing the details of how the various projects define their service/VNF packages/blueprints, i.e. get some concrete takeaway-value from the event. Further at this point my investigations into the documentation for the various projects indicates that there's little commonality so far in the data models used in blueprints, e.g. some reference YANG and TOSCA, but the models as processed by the VNFM/NFVO don't seem to derive from those standards, i.e. they are often in a project-specific YAML format. So perhaps we are too early in the development process to obtain useful takeaways from the VNF Portability scope of the Plugfest.
But I would like to give you a second chance to weigh in on this, and strengthen the rationale for this event with input on these questions. If we focused just on the VNFM and VNF blueprints for management of OpenStack VIM resources (e.g. compute, storage, network resources and topology): - What model representation does your project support, e.g. o tosca_simple_profile_for_nfv_1_0_0 ? e.g. see the blueprint https://git.opnfv.org/cgit/models/tree/tests/blueprints/tosca-vnfd-3node-tacker/blueprint.yaml o YANG ? E.g. see OSM: https://osm.etsi.org/gitweb/?p=osm/SO.git;a=blob;f=models/plugins/yang/vnfd.yang o Some other format in YAML or JSON ? E.g. JuJu Charm or project-specific schema If it turns out that both of the following are true, we should postpone this part of the Plugfest: 1) We have no more than a couple of participating projects 2) We have low expectations of there being a significant common data model support across those projects If we did have more than two participating projects, at least we could use the event as more of a hackfest to see if we can get the "vnfd-3node" blueprint working in your projects' specific format. Thanks, Bryan Sullivan | AT&T From: SULLIVAN, BRYAN L Sent: Tuesday, November 01, 2016 3:42 AM To: 'Carella, Giuseppe' <[email protected]>; 'FRANCISCO JAVIER RAMON SALGUERO' <[email protected]>; [email protected]; Sridhar Ramaswamy <[email protected]>; 'Sripriya Seetharam' <[email protected]>; Arthur Berezin <[email protected]> Cc: [email protected] Subject: Dec Plugfest Planning Hi all, Going out to OPNFV in general and specifically to those involved in the VNFM/NFVO projects OpenBaton, Tacker, Cloudify, ARIA, JuJu. I'd like to get your confirmation this week as to whether your organization/projects will be able to support the OPNFV Colorado plugfest at UNH-IOL, Dec 5-9: https://wiki.opnfv.org/display/EVNT/Plugfest+-+Colorado+Release and specifically the VNF Portability tests as described on the wiki at https://wiki.opnfv.org/display/EVNT/Colorado+Plugfest+Test+Cases. Since time is short for the event (1 month away) we need to quickly assess readiness for the event. I updated the wiki to more completely explain the concept and option for the test scope: VNF Portability Scope Overall the focus of this test scope will be to demonstrate VNFM product degree of compatibility with standards-based, reference VNF blueprints, as installed on one or more OPNFV deployment scenarios. It's expected that with the current generation of VNFMs, variations in blueprint schema support (e.g. product-specific extensions/limitations) will require customization of the blueprints, VNF images, or related support scripts. The reference VNF blueprints will be provided in advance, so that VNFM projects can prepare any needed customizations. Specific goals for the testing are 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. This initial plugfest will focus on: * the onboading, deployment, and termination phases of the VNF lifecycle, as described on the MANO WG wiki at VNF Onboarding<https://wiki.opnfv.org/display/mano/VNF+Onboarding> * relatively basic blueprint attributes, e.g. basic resource topology and requirements * potentially extending to further lifecycle stages (e.g. handing of in-service lifecycle events). Future plugfests will address other lifecycle stages, more advanced blueprint attributes (e.g. policy), and service blueprints (e.g. composed of multiple VNFs with service chaining). Other notes in advance: * If you can't support it in person, we can likely do some remote testing as well. * The test POD resources on the "Hello World" blueprint are pretty mild, doable in a virtual deploy. * The more advanced blueprints may require a multi-node POD or a full POD. We will need PODs that we can use for them, for that week at least (and the prior week for any pre-testing). * The tests we have prepared in the Models and VES projects depend upon JOID or Apex installs. You may have blueprints that work under other installs and that's fine. As noted below we can work to adapt the blueprints for testing also under the JOID and Apex deploys. * Further VNFM support (ARIA/JuJu, OpenBaton) in the tests will be developed over the next few weeks - collaboration on that is welcome! Hello World Purpose: * Assess portability of a very basic blueprint for a single/multi-node, multi-NIC web server. Procedure: See the examples for Tacker at vHello_Tacker.sh,<https://git.opnfv.org/cgit/models/tree/tests/vHello_Tacker.sh> and vHello_VES Demo<https://wiki.opnfv.org/display/ves/vHello_VES+Demo> which have the basic outline 1. VNFM is installed on the OPNFV system 2. Blueprint repo is cloned 3. Blueprint is imported into the onboarding system 4. Blueprint is started 5. Blueprint is functionally verified 6. Blueprint is terminated 7. Steps 4-6 are repeated several times without error or extra manual actions needed Note that the blueprints above will be updated as needed to run in generic TOSCA VNFMs or for DSL-specific node types as needed). Let us know your specific VNFM's compatibility ahead of time and we can work to close any gaps in how it's supported. Metrics / Expected Results: 1. Blueprint is successfully imported into the onboarding system (as applicable). 2. Blueprint is successfully deployed, including functional verification (web server responds as expected). 3. Blueprint is terminated and uninstalled successfully, leaving a clean system. 4. A minimal amount of blueprint functions require supplemental support, e.g. through scripts or image customization. More Advanced VNFs Purpose: * Assess portability of more advanced VNF blueprints, as can be developed in advance of the plugfest, e.g. * vIMS: Various versions of a vIMS blueprint have been indicated as supported by * Cloudify (Orange github version<https://github.com/Orange-OpenSource/opnfv-cloudify-clearwater>), as used in Functest. Note this depends upon an earlier version of Cloudify Manager and preferably would be updated to the current version before the plugfest * JuJu (Charm Store version<https://jujucharms.com/u/matt-williams-x/clearwater>, Metaswitch github version<https://github.com/Metaswitch/clearwater-juju>) * OpenBaton OpenIMS<https://github.com/openbaton/openimscore-packages> * BYOB (Bring Your Own Blueprint): let us know which blueprint (open source) you intend to validate on Colorado, and what test tools (e.g. VNFM) you intend to use. We will see if the blueprint is adaptable to other VNFMs for comparison at the plugfest. * Contributions to the Models project on this are welcome! Procedure: 1. Same in general as the Hello World test Metrics / Expected Results: 1. Same in general as the Hello World test Thanks, Bryan Sullivan | AT&T
_______________________________________________ opnfv-tech-discuss mailing list [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
