Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Platform should be more generic and we should work on quality(documentation, modularity,stability, model driven, generic APIs etc.)  As an example, even in a very simple usecase trial, we can struggle with inputs of functions and needs detailed documentation of each spec
  • For the VNFs we should have standardizied processes for onboarding and service function chaining. We should wait a more standardized templating in VNF deploys, making VNF’s more similar to each other at deploy phase.  
  • We should aim for ease of use and the minimization of customization. When implementing our requested cases, we needed to make minor-average code changes at core code; if that should be done, we should do it on gerrit avoding to build different ONAP clones with minor changes. That our requested  minimization of customization can make our open source product dependent from vendor spec; but duty here goes on to VNF providers to be reliable to some predefined -stronger- standards, what we mentioned at previous subject

 


Issues from our developers, 


  • Licensing: How to use the licensing models and its effects are not well documented. How do we check license violations and how to raise alarms?
  • Testing: Even testing the simplest use case requires lots of efforts. How do we check the integrity of ONAP deployment if all the pieces are working properly or not? Need automated integration testing after deployment. An initial set can be determined within any usecase or demo
  • Multiple VIM Support: We should be able to register at least two VIMs, one for the testing lab and another for deployment. We suppose it’s supported in Amsterdam but lack of documentation. May be some webinar; it is told that is talked before that some webinar will be done in future
  • Log management: Log management should be central. Infrastructure for central log management is ready in ONAP but not sure if all the projects in ONAP use the same logging mechanisms.
  • Health Check: OOM currently supports health checking of ONAP components. However, OOM deployment is not the only option. How can we health check in ONAP if heat deployment is used?
  • System Outages: When a system outage occurs, we experienced configuration loss and needed to re-configure some docker components and even needed to re-install VIM.


TELUS:

 

  • Geo-Redundant Highly available Network services/ONAP deployment 
  • Light weight/easy to install ONAP Platform
  • ONAP  Compliance with ETSI

-       SOL001 for Onboarding

-       SOL003 for Or-VNFM

  • Roles Based Access RBAC for deployment dashboard

-       Roles based access with fine grained attributes to support TELUS cross-function teams/security needs

  • Strong support for near-term VNF Onboarding use-cases

-       License key management, Template design + validation, VNF testing

  • VNF Day 2+ Configuration support (Modules architecture, Code Readiness)
  • Resource Orchestration visibility & control on cloud capacity