Python vs bash: does it matter? we should use whatever the contributor is most able to contribute. future convergence is an option but the priority is to promote contribution. the goal is upstream contribution of the tests thus if anything the tests should use the framework (and programming env) that the target upstream community uses.

It's unclear what the goal of this diagram is, and what the value to OPNFV is of representing its work/product as an "architecture"

It's unlikely that many OPNFV projects will be mapped (or can be) to specific components in the diagram

It is desirable to know where projects fit, but the mapping is likely to be imperfect

probably more useful to consider OPNFV's arch independent of the ETSI arch, e.g. focused on what OPNFV has released in each release, vs a mapping to ETSI (if possible this can be done after the OPNFV arch view is developed)

it's also perhaps more useful to focus architecture considerations on the upstream projects and how they are interconnected as architectural components

the architecture of OPFNV-driven reference platforms will also evolve over time, e.g. the transition to cloud native may radically change the "architectural view"

(Prakash comments on the arch page) In Models meeting discussions it was highlighted that mapping of OPNFV projects to release architecture is more important to the title of the page. Plus the granularity of this diagram is useful but info graphics need not be high priority. Mapping between this and MANO terminology can be taken up later. More important is the upstream architecture and how they get integrated through specific projects in them. Visuals are only cue to perspective and can be many.

Status of current work

Some updates to the vHello_Tacker test

Beyond getting Danube test env running (still working on that), the goals for Danube are just to update the existing tests for Newton

Upcoming/Planned

Recap of YANG discussion with Peter

Requested by Alex

2017-Feb-6 Models Project Meeting #24

Agenda:

Status of current work

Upcoming/Planned

Recap of YANG discussion with Peter

Requested by Alex

Attendees:

Bryan Sullivan, AT&T

Alex Vul, Intel

Arthur Berezin, Gigaspaces

Amir Levy, Gigaspaces

Krzysztof Frujacz, Gigaspaces

Trinath Somanchi, NXP

Sridhar Pothuganti, NXP

Aimee Ukasick, AT&T

Minutes:

Status of current work

Difficulty with standing up OPNFV Danube test environments has pushed Models out of the Danube release

Bryan: trying to get Packstack running with Tacker on stable/newton as a backup, to keep development moving

Amir: Aria should be near-ready for testing

Taking on discussions for blueprint proposals

Alex to provide intro to Open-O data models and Aria use in it

Documentation baseline (skeleton) has been setup by Aimee and merged

2017-Jan-23 Models Project Meeting #23

Attendees:

Bryan Sullivan, AT&T

Amir Levy, Gigaspaces

Krzysztof Frujacz, Gigaspaces

Trinath Somanchi, NXP

Sridhar Pothuganti, NXP

Aimee Ukasick, AT&T

Chris Lauwers

Minutes:

Status of current work

vHello_tacker tests on Devstack

We are testing against stable/newton.

Trinath is trying vHello_Tacker.sh and needs help with setup, e.g. local.conf for Devstack, workstation config.

i7, 8-core, 16GB RAM, 1TB disk

Xenial VM, 8GB RAM, 20GB disk, 2 cores

vHello_tacker tests on OPNFV

Upcoming events

OpenStack PTG Atlanta

Tacker will not meet. Any other models-related meetups needed?

Suggest a post to the list if so.

ONS

ISubmitted by Bryan: Model-Driven NFV in OPNFV Danube

A key goal for the NFV transformation is that everything possible should be automated through model-based abstractions that enable orchestration and management systems to seamlessly adapt VNFs to a diversity of infrastructure environments. These model-driven NFV goals go well beyond basic resource topologies, e.g. into lifecycle management, various types of policies, and telemetry. In this talk we will cover and demo the OPNFV Danube release support for modeled VNF deployment and lifecycle management through TOSCA-based blueprints, and the roadmap for additional model features.

Execution plugin is being worked on first (SSH and execution of scripts as "implementation" hooks)

How does it manage stateful as well as static blueprint data

Both need to be auditable (give me the current state in some easily usable/comparable form, e.g. JSON)

Stateful data needs to be reliably stored - is this a database sync issue only?

How does it support update of the deployed instances, e.g. to add a new node in the graph or update a node

Plans beyond CLI and Python libraries

The vision discussed at the ODL Summit was for a RESTful API thru which we can onboard blueprints, deploy, and interact with the deployed instances as objects (e.g. JSON-based), for a completely modeled/object-based abstraction layer

Basic VDU properties supported?

Intend to support TOSCA profile CSD03 (all nodes): current YAML implementation of the schema

Peter described OpenCORD approach - see the References page for notes on OpenCORD.

Modeling approaches - collecting perspectives on

What ETSI is recommending in their current drafts and why

Bryan will reach out to Francisco Javier for feedback.

The role of YANG in service/application control

Seems there is significant consensus on this, e.g. in OpenCORD and ECOMP approaches. Details will be added to the wiki.

How service and VNF modeling works in OpenCORD today

Additional details will be added to the wiki based upon the references Peter provided.

If YANG was used at the service and VNF layers, how we can derive TOSCA NSDs/VNFDs etc as needed for processing by the cloud controller components e.g. Tacker?

We seem to have a common overall goal of a model-based abstraction that can be interacted with by upper-MANO stack components (or other service components), which is then by some service/application control framework, is bound to specific actions to be taken at infrastructure managers (e.g. cloud, SDNC, or application-directly-exposed APIs). Examples of this approach will be added to the wiki, e.g. ECOMP's ODL-based Application Controller, or OpenCORD.

We need to describe (for different projects/approaches) the overall process/toolchains for taking a high-level service/VNF abstraction thru the transformations needed to execute specific infrastructure management actions. That should help us come to a common understanding at least.

Open-O should be there (participation in VNF Portability is TBD): Lingli and Chris

POD resources: what resources will be needed should be known asap

Update the Resource Requirements section of the plugfest page

Models Team Meeting B at 0000 UTC

Will start the bridge etc

Status of committer pool etc

Bryan so far has been the sole active contributor/committer to the Models repo. Additional reviewers/committers are welcome to get involved in the project, and I can slow down the speed of commits as needed to enable team members to come on board. More active committers can also help establish more conventional practice for commits etc, a good thing for the project.

"Architecture of OPNFV" re CVP program and goals for what we can claim in 1st release of CVP

Where how this will be addressed is TBD

MANO WG should be a good venue for it

Prakash has a draft diagram; some open issues e.g. underlay arrangement, service assurance

Dan: 2 levels i.e. VNF and service; testing discussions should clarify the VNF and service design handoff, and that VNFs are reusable; both VNFs and services can be onboarded. Tacker as an example has this distinction and two separate catalogs for them.

MANO WG intro

Few comments overall

Clarified that the role of Models project is to "assess and advise"

Send out a notice for the PM PST timeslot for Models; Prakash will send for MANO WG as well.

Charmers meetup

Since JuJu is a common MANO stack element across projects, being familiar with its DSL is important

Bryan showed the current work on the vHello_VES model, with App VM (nginx-based web server), VES Monitor VM. Will add LB VM (iptables), a 2nd App VM. This will enable us to add scaling to the blueprint, through TOSCA scaling policies (hopefully supported). The VES demo will include various lifecycle events for which the intended handling should (if supported) have some modeled aspects, but for now will have scripted handlers at least.

Main takeaway for Models: "Current focus in the Models project is on the first steps of deployment (instantiation) but we can expand into the onboarding phase as we get resources; it will be better to converge the work in a single project in OPNFV, with the larger frame/goals set by the Polestar and MANO WGs."

Danube project planning

Modeling the injection of parameters into VMs, e.g. for "VES support in blueprints"

Bryan will propose some Epics, Stories, Tasks etc

The team is encouraged to watch, comment, add more, etc

Cross-project items

Catalog: the OpenStack Community App Catalog and its Horizon plugin used by Murano etc; for Models and OPNFV more broadly, we should use this feature (integrated into Danube) as a place to reference (and provide users the ability to launch) the VNFs that have been tested on the OPNFV platform

Domino project Cross-WAN L3VPN use case: Domino includes some use cases for NSD distribution across multiple sites, with elements (VNFs) of a service distributed across the sites, and thus the need for connection point links setup across those sites, e.g. via L3VPN. Extracting the L3VPN component of that goal and developing it as a Models use case seems useful - for the two cases:

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 installer (cloudify-setup.sh) is working but starting the blueprint is failing (timeout installing the Cloudify Agent n 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 config-drive 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 vm-config-demo.docx demo log file (which combines a demo of the Hello World Tacker test and the Copper smoke01.sh 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.

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 EUAG.

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 them.

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.

2016-July-31 Models Project Meeting #11

Attendees:

Bryan Sullivan, AT&T

Guiseppe Carella, Fraunhofer Fokus

Larry Lamers, VMWare

Prakash Ramchandran, Huawei

Dan Druta, AT&T

Alok Gupta, AT&T

Artur Tyloch, Canonical

Uri Elzur, Intel

Agenda:

Status of Colorado release work

Takeaways from the OPNFV Summit

Modeling in the broader topic of VNF Onboarding

In the end-to-end lifecycle of VNFs/Services, the onboarding phase needs to be broken down

The two session proposals by Uri and Bryan are merged into one, titled: MANO modeling: Service, Infrastructure and VNF On-boarding and Interoperability

“MANO is one of the critical layers for NFV realization, yet industry direction on it is in danger of diverging. Along with closed implementations, open source projects such as OSM and Open-O are now driving MANO implementation. To help drive broad convergence and ease Service development, VNF on-boarding, and interoperability, we need broad agreement on Information Models and Data models. We will present a proposal to use TOSCA/YANG as a basis for this, and report on efforts in OPNFV to validate and promote convergence in support for model-driven Service and VNF deployment on the OPNFV platform. This talk will be supplemented by a demo of the current work in OPNFV to be presented in the demo theater.

Bryan will upload a draft of the second part of this talk this week for review.

Focus on the data models that developers will be expected to prepare for onboarding.

Show the process of onboarding and deployment including any translation steps

These examples can be used in Functest to provide a deeper use case testing that e.g. runs every two weeks on the various scenarios

Describe some of the implications of the different modeling approaches and tools

2016-May-23 Models Project Meeting #8

Attendees:

Bryan Sullivan, AT&T

Artur Tyloch, Canonical

Marc Flauw, HPE

Agenda:

Intro to Models project for Artur (Bryan)

First goal is to have a working simplified blueprint that we can drive with multiple VNFMs/NFVOs in functest

Real VNFs would be great but are optional.

Status of OSM (Artur)

OSM Release 1 (see wiki) will be released over the coming months. Release 0 is what was presented at MWC.

The role of components in OSM (principally rift.ware and Juju) will be evolving, with Juju taking on most of the VNFM functionality including YANG-based application control/lifecycle (something not yet considered in ETSI, but important overall for NFV).

Status of ETSI specs (Marc)

Still planning stage 3, current stage 2 specs go into more detail but not yet fleshed out at stage 3 level

IFA011 (VNFD) and IFA014 (NSD) will be furthered as stage 3 models in the SOL group

IFA007 (NFVO) and IFA008 (EM) (VNFM interfaces) will also be modeled in the SOL

The two session proposals by Uri and Bryan are merged into one, titled: MANO modeling: Service, Infrastructure and VNF On-boarding and Interoperability

“MANO is one of the critical layers for NFV realization, yet industry direction on it is in danger of diverging. Along with closed implementations, open source projects such as OSM and Open-O are now driving MANO implementation. To help drive broad convergence and ease Service development, VNF on-boarding, and interoperability, we need broad agreement on Information Models and Data models. We will present a proposal to use TOSCA/YANG as a basis for this, and report on efforts in OPNFV to validate and promote convergence in support for model-driven Service and VNF deployment on the OPNFV platform. This talk will be supplemented by a demo of the current work in OPNFV to be presented in the demo theater.”

2016-May-9 Models Project Meeting #7

Attendees:

Bryan Sullivan, AT&T

Mark Flauw, HPE

Agenda:

Review of previous meeting

Updates to epics/stories in Jira

R3 project plan and minimum goals

Model analysis status

Tools analysis status

Model testing status

Recent events

NFV World Congress

OpenStack

Upcoming events

OPNFV Summit

Minutes (#A) :

Reviewed the last meeting's results since it has been three weeks.

The JIRA epics/stories will be updated with additional info as requested by Gergely, so the nature of the tasks is clearer.

But overall the intent in this project is not to over-depend upon the JIRA tool for project tracking, as the nature of the project is different from one that is developing a lot of code.

Plans for Colorado at this point are to:

Generate a test framework for model validation across multiple VNFMs, and include this in FuncTest

High-level focus will be on assessing the state of IM at ETSI and relation to the DSLs of TOSCA, YANG, etc, and include this first in the wiki, and then in a report.

Marc:

ETSI specs and models are UML-based (IFA015), IFA011 goes into details such as element hierarchy in a text/table presentation, still at stage 2.

The SOL group is codifying the stage 3, e.g. SOL001 (TOSCA-based NFV NSD).

The scope of the SOL work is to develop a data model specification for NFV descriptors fulfilling the requirements specified in GS NFV IFA 011 and NFV GS NFV IFA 014. The specification will be based on the Simple TOSCA profile specification for NFV with possible changes. The deliverable will contain normative provisions and an informative

The paper and and deck describe how a use case (OMA Secure User Plan Location (SUPL)) might look as a TOSCA-based blueprint. I will be using and further developing this as an example in the Models project.

Other OMA enablers to be used as examples include the OMA Device Management enabler Lightweight Machine-to-Machine (LWM2M), which defines a IoT-focused DM framework for constrained devices/networks (e.g. sensors and other industrial/consumer devices over LPWA access). OMA LWM2M is the lead technology being developed in the IoT market for managing and accessing data of IoT devices.

Other than verifying ability to launch an enabler via a modeled topology, these use cases depend upon open source implementations of the actual enabler components.

In the meantime I am working with implementers to support the use case testing thru their proprietary implementations, and also looking to use existing open source enabler implementations as noted on the Models wiki.

A key question is whether we need to look at these use cases from a DSL view or a higher level view

Marc:

Suggest to start at the DSL level for use cases as the UML/IM level is intended to be more conceptual and language independent, even use-case independent (the classes do not represent use case considerations rather generic usable concepts that can be implemented thru the DSL)

IM's can help to assess the consistency of the little pieces of the problem space, e.g. classes, e.g. services, service chain, etc...

The IM should also enable the relationship description at the UML level and below.

e.g. the concepts of client and server in context of a particular service

Bryan:

It may thus be useful to start at the UML level for service use cases that may be applied to different service environments, e.g. a web service that can be deployed for browsing, APIs, end-users, and IoT applications

Such a web service might include a proxy, cache, and other network functions that can be modeled in terms of their function, relationships, and position in a service topology

2016-April-11 Models Project Meeting #6

Attendees:

Bryan Sullivan, AT&T

Prakash Ramchandran, Futurewei

Gergely Csatari, Nokia

Ulas Kozat, Huawei

Tianran Zhou, Huawei

Agenda:

Selecting a new meeting time

Contributors to various epics/stories

R3 project plan and minimum goals

Events plan

Model analysis status

Tools analysis status

Model testing status

NOTE: Bryan got the meeting time wrong and started an hour too early, thus Marc was not able to join. Models #A Meetings starting next week will be at the expected time (16:00 GMT).

Minutes (#A) :

Prakash requested clarification of what types of model validation (e.g. mulit-node cluster, network links for relationships) will be supported.

Bryan: That's a question we need to address thru use case focus. The existing VNF implementations will be used as a template for other use cases, more narrowly focused (my suggestion).

Csatari: The use cases refer to reference VNFs, but should be more abstract e.g. scaling (would like to see the use case description updated)

Bryan: they can be to start, but to drive specific model analysis or test activity, they need to get more specific

Prakash: re scaling, I think the best will be take simple VNF scaling with single VDU and another with 2 VDUs and get some models and see how it pans out

Prakash: continuing on the subject lets take Simple TOSCA model for VNF and compare that with YANG or UML, and see what the scaling parameters are. I am looking for scaling attribute in VNF if it is usable from TOSCA or YANG and how do they differ for a VNF scaling use case. See http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv-v1.0.pdf

Ulas: current models are simple, as a scale attribute one can specify number of instances. At the end of the day, these are all {key,value} pairs If you want to define a scaling property in yang, is there a limitation? It is up to you how you define new nodes, policies, properties, etc. If you want to scale a collection of things in Tosca, you can group them and attach a scaling policy

Prakash: I think we have to start with use case scaling is just an abstraction , so what is then the use case not scaling but a service and modeling service will inolve first lets say network service consists of one VNF with one VDU and so on. See Policy Example - I; under policies tab "mu_anti_collocation_polic" is something quite arbitrary

Ulas: see Policy Definitions, this is actually more informative. For instance you can define a VNF (which is a node) composed of multiple VDUs and then define some properties to represent the bandwidth constraints between VDUs. Then you can specify some triggers based on the values of these properties.

Prakash: we need to look at models as what they represent based on Information models and not data models; For a given use case we need to start at Common Information Model, but then that still will need topology representation. So TOSCA puts models in terms of VNF, and now where as YANG puts it in terms of network node, is that a fair statement?

Ulas: It is up to the model author to be generic or specific (informational vs. data model) and both Tosca and yang can deliver information and data models. One can also describe the internal workings of a high level service also in yang, isn't this the case?

Prakash: Abstract vs. concrete is really the difference so we need to choose an abstract, concrete or hybrid way to model logical network service.

Ulas: Currently Tosca is a mixture, e.g. you can specify OS and hardware in Tosca; you can also leave it at "flavor". A VDU can still be abstract, as a unit of scale you need to add/remove resources at that granularity.

Prakash: VDU is already mixing the concrete and abstract in TOSCA. A Flavor is good for Compute service in OpenStack, still evolving in Network Services in Nova, so we will need to agree on some basic elements for both TOSCA and YANG as two main modeling for network Services, for Applications it has always been UML.

Minutes (#B)

Bryan described the Models 1st release focus per the last meeting notes (see "minimum goal for R3" below). In summary using the complex VNF model described by https://github.com/Orange-OpenSource/opnfv-cloudify-clearwater/ as a starting example, we will create a simpler one as an extensible template for model testing in the Colorado release, using various VNFMs to assess the degree of model portability.

Tianran intro'd his involvement in IETF etc, for models in MANO area. His team is involved in "Carrier SDN" (generic term) work in TOSCA.

This will include single node and multi-node cases. The multinode case will use TOSCA relationships to establish inter-VM network connectivity. The examples will be very basic since they are intended to be a basis for further VNFD attribute tests.

The R3 planning is complete AFAIAC, but if anyone wants to get more specific re the JIRA items then feel free. Same for the Wiki - I think it's pretty good as a starting point, but contributions are welcome.

My minimum goal for R3 is as above, to establish a baseline for test development as part of the CI process, to augment the existing vIMS tests and further flesh out VNFD features as time permits. At least one VNFM (Cloudify) will be included, but support for others (JuJu, Rift.ware, ...) will be included given time and contributors. Since vIMS is (AFAICT) supported by all installers, a related goal will be that these tests will also be included in all CI runs. If that for some reason doesn't pan out (e.g. installer code freeze dates are too aggressive), the tests will be available at least as a post-install test suite.

2016-April-4 Models Project Meeting #4

Attendees:

Bryan Sullivan, AT&T

Agenda:

Status of project setup: Git, JIRA, Wiki

JIRA epics and story overview

Contributors to various epics/stories

R3 project plan and minimum goals

Events plan

Model analysis status

Tools analysis status

Model testing status

2016-March-21 Models Project Meeting #3b

Cancelled (no show)See the Meeting #3a for minutes.

2016-March-21 Models Project Meeting #3a

Attendees:

Bryan Sullivan, AT&T

Serge Manning, Sprint

Lingli Deng, China Mobile

Agenda:

Status of project setup: Git, JIRA, Wiki

JIRA epics and story overview

Contributors to various epics/stories

R3 project plan and minimum goals

Events plan

Model analysis status

Tools analysis status

Model testing status

Meeting summary

The overall goal for the meeting was to share and get input on the project setup work so far and planning for R3

we can share the same model for testing across SDNCs to validate interop

Ulas: transportability of Tosca templates is a similar goal

Ulas: testing SFC in detail will require validation of each hop in the forwarding

Ulas: more complex test cases will require a formal model for the expectations so a test framework can validate it

Prakash: distribution of the templates is needed for policy that is applied across different domains/locations

We may take a 2nd look at the meeting time for the AM PST call; Ulas has a conflict at 8-9 AM and this is why he was able to attend this session.

2016-March-7 Models Project Meeting #2a

Attendees:

Bryan Sullivan, AT&T

Mark Flauw, HPE

We had issues getting the bridge to work, still need the logistics setup with the help of LF:

GTM bridge

Git repo

Jira project

IRC meetbot for #opnfv-models

Bryan Intro'd the draft deck for ONS: https://wiki.opnfv.org/_media/ons_models.pptx. The focus of the talk will be on what needs we see for Info & Data Models in NFV, what activities OPNFV is starting for the Models project, and the background info we have collected so far. Things I have found in the last week:

The 2nd slot ('b") for the Models weekly meeting will be at 4PM PST Mondays. Bryan will find a GTM link we can borrow in the meantime until LF allocates one.

2016-Feb-29 Models Project Meeting #1

Attendees:

Bryan Sullivan, AT&T

Serge Manning, Sprint

Mark Flauw, HPE

Pierre Lynch, Ixia

Christopher Price, Ericsson

Pasi Vaananen, Stratus

Steve Furr, NXP

Agenda:

Project goals =

Open discussion and scoping (down) of the project goals for R3/C as needed.

Two main threads emerged in the call:

(1) SDO outreach and model convergence assessment/promotion;

(2) testing/demo of current model-driven design in current developer tools and platforms (including OPNFV Brahmaputra + extensions, and other adjunct tools e.g. orchestrators). Further clarification of these will take place thru Jira.

Project lead

In the meantime I can continue as project lead, but I would be fine with someone else stepping up to the role, since I'm already lead on one project (Copper).

Bryan: Any day seems to work - we need to pick one, and to keep it simple I recommend Monday as well.

Tools: Jira, GIT, wiki, etc

a. Discuss how we will use these tools

Familiarity and regular use of the tools varies in the team. No specific suggestions so far on how to use the tools. We can just get engaged thru the tools and see who takes to what roles.Suggestions made by Bryan during the call include:

Jira for setting up the general structure of focus/tasks and SDO interaction, getting more specific as needed as we go.

Git/Gerrit for documents and other artifacts in development, pending determination of how familiar/comfortable the team members are with editing or submitting change requests thru "patching" documents etc. In the meantime, Bryan can help out as editor and incorporate suggestions thru calls/email/etherpad/etc into docs as needed.

Wiki and etherpad for general idea development and documentation. Rich media (e.g. Powerpoint, Gliffy, Word) can also be used and captured on the wiki prior to ingestion into docs as needed. Most important is collection of info/ideas with minimal impedance.

Jira task setup

a. Types of docs we will develop

introductory docs with background clarifying the role of different types of models

inventory of references to standards-published models, and models published through other places

references to UML modeling from SDOs and related tools

normalizing model representations

derivation of models from open source implementations

references to open source implementations of network functions that could be used in PoCs/demos

use cases to be validated and test strategy for each

reports published for each release covering

Cross-project, SDO, and upstream collaboration

use cases, models, platform components, and standards validated

issues identified

requirements for upstream projects based upon prioritized gaps

Chris pointed out the importance of working with the Functest and other testing teams on the use case validation.

Bryan agreed clarifying the intent to develop a use case testing plan and strategy, and after some initial manual use case development, to work toward the goal of integrating the use case tests into the OPNFV functest library for ongoing automated testing.

Bryan mentioned that unless we get into the mode of multiple direct contributors to docs etc thru git/gerrit (with gerrit-based reviews/comments/etc), he and the other committers can fast-track changes that are suggested and the group can review the results, suggest corrections etc.

Event planning

Discussion/hackfest/demo plans for ONS/OPNFV and other events e.g. OpenStack