Versions Compared

Key

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

...

We should continue working on platform quality (including declarative model, service layer abstraction, modularity, S3P etc), dedicating it 2/3 of the development time (comparing to platform's functional enrichment.


Orange:

We should continue working on platform quality (including declarative model, service layer abstraction, modularity, S3P etc), dedicating it 2/3 of the development time (comparing to platform's functional enrichment.

Improve deployability first

  • Get a stable version and improve the integration process for the change code.
  • Provide additional tooling to operate the platform:  backup&restore, ONAP software upgrade, log vizualisation, tools to manage credentials, RBAC.
  • Get UI tools to help writing the VNF package.
  • Get more tools to validate the workflow, directed graphs, micro-services, policy rules. Capability to manage versions and how to minimize impact with VNF new configuration models
  • Provide more guidelines how to use the components, how to start with ONAP, to learn ONAP.
  • Avoid every hardcoded code to run the use-cases

Improve functional level

  • Keep the best modularity level
  • Manage mass VNF configuration: eg upgrade of a large number of same VNF type (eg entreprise FW in various OpenStack) and provide audit tools to check the VNF configuration.
  • While most services will require PNF integration, include PNF management.
  • Improve consistency between underlying infrastructure and AAI typically in configuration with multiple VIM
  • Include license management (SDC includes some modeling, but there is no code associated with it)
  • Cloud-native VNF to be deployed on Kubernetes.

Improve sharing

Better share all the PoC/deployments realized with ONAP

Other

Clarify the global VNF certification to be integrated with ONAPOther more detailed requirements will come shortly.

China Mobile:

it is really important to make ONAP as a generic platform to run all the use cases.

...

  •  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

 


Our main usecase and requirement orientation will be towards (from highest to lower): 


  • Compliance with ETSI
  • OSAM
  • 5G

...


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

...