The document summarizes discussions from a Parser breakout session at the June 2016 Berlin OPNFV Summit. Key topics discussed include: 1. Release C work including patches to OpenStack Tosca Parser, Yang to Tosca conversion, policy to Tosca conversion, and Tosca to Kubernetes conversion. 2. Release C testing and integration work including individual module installers and testing scenarios. 3. Ideas for Release D including making the Parser microservices work together through a common API, improving testing methods, and defining relationships between modules and results. 4. Brainstorming on using machine learning in the Parser including detecting fraudulent templates and understanding user intent through supervised learning on tags.

1. June 20–23, 2016 | Berlin, Germany

2. Parser Breakout Session

3. Session Agenda
•Release C process review and troubleshooting
• tosca2heat
• yang2tosca
• policy2tosca
• tosca2kube
• Rel C testing/Installer issue
•Release D brainstorming
• Microservice
• Machine Learning

4. Release C - tosca2heat
•patches to OpenStack tosca-parser
• in Newton release
• https://review.openstack.org/#/c/329971/
• need to get merged, also documentation work for Rel C.
• merged in Mitaka release
• https://review.openstack.org/#/c/314666/
• https://review.openstack.org/#/c/310359/
• need documentation on these for Rel C doc work

5. Release C - tosca2heat
•JIRA tickets in OPNFV
• https://jira.opnfv.org/browse/RELENG-108?jql=assignee%20%3D%
20shangxdy%20AND%20resolution%20is%20EMPTY
• 5 tasks, 7 bugs, 3 stories opened as of Berlin Summit
• Bugs are ok to be closed, 3 stories are good on target, at least 1 task is on
track

6. Release C - yang2tosca
•Parser UI

7. Release C - yang2tosca
•Parser UI
• will upload the code to Parser repo after summit
• policy support is there, but not ETSI/tosca compliant.
•yang2tosca enhancement
• most of parts are done. Code will be uploaded later.

8. Release C - policy2tosca
•https://wiki.opnfv.org/display/domino/policy2tosca https://etherpad.
opnfv.org/p/policy2tosca
• policy2tosca CLI will be ready in Rel C
• Two features needed:
1. Policy Composer
a. Derive classes from the TOSCA base classes
b. Define fields
2. Policy Rule Insertion to NSD
a. Pull a previously defined policy type via policy composer
b. Provide trigger and target definitions
c. Provide rule descriptor

9. Release C - tosca2kube
•Have an initial idea on the work plan
• technology wise - solve the necessary mapping between tosca and k8s
• k8s parsing function could be found at https://github.
com/kubernetes/kubernetes/blob/master/pkg/api/v1/types.go
• to have k8s to have a more official document on the template definition.
• maybe starting from compute and storage.
• For release C only document could be delivered
• scenarios wise - input from Yardstick team
• TBD

10. Release C - installer and testing support
•each individual module in parser handle its own installer and testing
support.
•For installer, all the modules are expected to deliver a pypi package
to help the installer team to integrate.
•For testing, more scenarios ?
• same scenario with more features for yang2tosca
• new scenario to verify the patches in tosca-parser for tosca2heat

11. Release D – Make Microservice Work
•Parser has a microservice architecture, how to make it work ?
• Expose a common API. Do we need API-GW for Parser ?
• Have an efficient testing method and framework
• Define logic between modules.
• Define the relationship between the intermediate and the final result

12. Release D – Machine Learning in Parser
•Airbnb Example

13. Release D – Machine Learning in Parser
•Airbnb Example

14. Release D – Machine Learning in Parser
•Parser ML design thought
• The security risk for Parser is malicious template. (e.g fake VNFDs to make
unnecessary resource reservation to drain out the session) Parser ML need to
be able to recognize false claims defined in various templates.
• To have models for fraud templates.
• ML scenarios are not limited to security. For example Parser could use ML to
understand the intent of the same tenant, so that later request could be made
in the format of intent instead of complex templates.
• Use tags to identify what are the keywords of the intent.
• Supervised ML with user provide feedback on the right choices of the tags.
• Parser is session based mostly. Would it be event-based in some case ?

15. Release D – Machine Learning in Parser