Release 4 (Dublin) Service Providers (EUAG) Requirements / Proposals

ONAP should have the ability to model running instance of VNF / NS ( aka Resource for convenience ) and associate it as part of NS design.

During Deployment, Runtime should first discover existing instance of such resource. If such resource is not found, then based on NS design, the said resource has to be deployed in real-time and tied along with current NS. Decision to either stop deployment, rollback deployment, retry or create such resource will be part of design time decision.

During resource design, a choice has to be provided to specify whether running instance of this resource could be used as part of NS design ( as per above flow ).

All other LCM aspects of the said resource ( scaling / healing / discovery / termination ) has to be looked as well.

Note : One of the possible way is to perceive this running instance of VNF as a PNF ( aka black box ) in modelling by providing endpoint URL along with Payload. But this solution doesn't scale well and doesn't solve the problem holistically. Hence need a better solution.

During the Casablanca timeframe, Controller Design Studio has emerged. The goal with CDS is to create a common platform to all controllers - providing design capability to define controller blueprints (e.g. the WHAT) and data dictionaries (e.g. the HOW). The blueprints are using a JSON TOSCA based representation. CDS currently lives under CCSDK project, but still requires enhancements that are not achievable in the Casablanca timeframe. There is a list of enhancements planned for Dublin available here : https://wiki.onap.org/pages/viewpage.action?pageId=41422551 Self-service is a broader need across ONAP, and in order to address the needs of operational teams for configuring network resources this is a first step.

Support for Database as a Service; Several applications are using MariaDB or Postgres, while all independently maintaining their databases. With Casablanca, several of those databases have now redundant instances for HA needs. The goal would be to allow for consolidation of those databases to minimize overhead, where it makes sense - while maintaining the flexiblity to deploy them independently based on the needs.

Implementation of a proper CI system providing daily feedback using the full robot suite (e.g. run distribution and instantiation) on the state of all our branches, whether release branches or master. An example of such CI has been implemented at various place, but would be good to see that integrated within ONAP CI system. This will allow to catch regression issues way earlier in the development cycle.

Currently AAF implements the SMS component for secure storage, but it is not leveraged throughout the platform (i.e. AAI ESR cloud-region credentials). In order to use the system in production, we can't be storing information in A&AI in plain text (such as device or cloud-region credentials). ONAP needs to store any credentials for the devices & environments it manages in a secured/encrypted fashion, so that they are - for example - not published along with inventory data.

Currently, Metadata values passed by VSR package can contain values that are either not compliance to ONAP standards or not compatible with the installed VID environment that can lead to deployment failures. This proposal proposes to add dynamic checks within SDC to be able to check passed metadata values against a registry that contains the check criteria. the content of the registry can be pre-loaded with standard static criteria, but also can be configured to add custom checks that are related to specific VID deployments.

Full proposal is here:

VSP Compliance Check within SDC (Dublin) - Phase 1