Attendees: 

Atul Purohit, Olivier Augizeau, Ryan Hallahan, Scott Blandford, LIN MENG, Vincent Colas

LF: Jim Baker , Kenny Paul



Notes from meeting

Review of the templates and priorities collection process

Orange priorities

Top priorities

  • Automation is focus
  • VNF and PNF

ONAP

  • Scenarios are useful but not sufficient - need more ala carte for satisfy telco requirements
  • ONAP not mature enough
  • Need a security framework
  • Will use slide templates that Atul provided at a later time


Vodafone Priorities

Top priorities

  • ONAP platform modularity
    • ONAP is all-or-nothing
    • API maturity issues - would like more plug-n-play interfaces between modules in ONAP
      • See NetTracker
    • ONAP PTLs demonstrate reluctance to re-factor code to improve modularity
    • ?Is this requirement beyond modularity - seems more like plug-n-play?
      • Yes - would like to combine modules that are independent - one module at a time
    • ?Isn't a simple matter of just selecting the modules in the info.yaml before the build?
      • Could define the .yaml automatically?
      • It's more of a problem of how well the modules are integrated AND open for inclusion of non-ONAP modules
      • On deployment, it is important to ONLY use external APIs and none of the ONAP internal APIs
  • Technical platform maturity - Vodafone has filed defects on each issue as discovered
    • Pods crashing due to cert issues/db issues and no documentation
    • Manually must run SQL queries by going into the container
    • Logs are incomplete
    • Readthedocs does not match the gerrit info
    • Health checks fail even when pods are running fine
    • Encounterig version issues in charts with different containers
    • Health checks fails although components are running fine
  • Infrastructure abstraction - see CVC VNF MVP definition
    • Infrastructure still tied to VNFs
      • Not an ONAP issue, but vendors are still looking at specific infrastructure abstraction (how VNF can work with underlying NFV)
    • Standardization isn't standard - there are quite a few options in standardization
    • Want TOSCA and Heat templates for VNFs
      • Only a handful of requirements and validation test for TOSCA
        • Need a more robust community around TOSCA
  • Implementation info/docs
  • Automation for 5G
    • Ben Cheung/Alla have a large backlog of requirements
    • ?What is delivered in ONAP - Scott Blandford mainly 5G planning oriented - some basic on-boarding 


SwissCom Priorities

Priorities relayed by Email (David Perez Caparros)

1) Documentation & Usability
- As already mentioned in the last F2F meeting in San Jose, documentation is highly scattered across wiki, mailing list, readthedocs. 
- It is not clear which documentation is still up to date
- Not clear which functionalities are implemented and available in the platform, which are planned for next releases, which are just ideas
- Documentation is usually meant for developers of a specific project, not operator/user oriented, no e2e view
- Portal UI does not provide a consistent e2e view of the platform functionalities
        - Difficult to operate. Multiple UIs, many of them not directly accessible through portal, e.g. DG builder, SO monitoring, Consul...
        - Issues with certificates when accessing different project UIs, e.g. CLAMP, VID… 
        - Some project UIs only accessible with a certain browser.
- Need for end user tutorials, not only project specific, but with an e2e view, e.g. up to date step-by-step guide for running use cases

2) Platform maturity
- Model driven. No code changes required whenever new services are defined, e.g. extensions to SDNC Generic Resource API require code changes and redeployment of SDNC
- Service design should be contained in SDC, e.g. SO requires additional DB insertions for mapping resource models to BPMN recipes before service distribution
- More unit testing is required before releasing code
- Upgrading components sometimes breaks the platform


EUAG input to other projects

  • Should be a prioritized list of requirements provided to the ONAP TSC
  • ONAP is a volunteer economy - what developers/organizations are willing to work-on is a what gets done
  • PTLs review plans with the community and solicit staffing
  • While the TSC has the final decision, it is based on the PTL feedback on what resources available for a release





Chat Log

06:57:49 From Kenny Paul (LFN) : https://www.onap.org/wp-content/uploads/sites/20/2018/11/ONAP_CaseSolution_5G_112118FNL.pdf
06:58:51 From Jim Baker (LFN) : DDF registration: https://wiki.lfnetworking.org/pages/viewpage.action?pageId=15630372