EUAG 2019-05-21 meeting minutes

Owned by Jim Baker
Last updated: May 21, 2019
3 min read



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://lf-networking.atlassian.net/wiki/pages/viewpage.action?pageId=15635936