...
- Regarding the platform, it is important to continue working on S3P requirements for Casablanca to increase platform quality.
- Documentation and information sharing is key for end user adoption. We see scattered documentation between readthedocs and the wiki. Meeting recordings and minutes, contributions and project description are not always up-to-date, making it difficult to keep track of discussions.
- On use cases for Casablanca, our initial priority would be OSAM, 5G and edge automation. Specifically, working towards supporting the deployment of fixed access services composed of both PNFs and VNFs, improving PNF onboarding and management capabilities, and defining a lightweight ONAP that can sit at the central office and how central ONAP interacts with it.
Turk Telecom:
- 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.