Page History

...

Abstract

This proposal is to add dynamic checks within SDC to (1) check compliance with deployment environment criteria, in order to reduce deployment failures; and (2) check for prior certifications, to eliminate unnecessary tests during onboarding.

Rationale

(1) Currently, metadata values passed by the VSP package can contain values that are either not compliant with ONAP standards or not compatible with the installed VID environment that CSP installed deployment 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.

Rationale

Reducing the risk of VNFs failing to be deployed in a given Virtualization infrastructure deployment VNF deployment failure. Reducing the risk of such failure can be achieved by checking the metadata passed by the VSP against some defined criteria (both coming as part of a standard, and also configured for a specific environment).Examples of metadata to be checkedcriteria in VTP or third-party repositories. Examples of metadata passed by the VSP to be checked for compliance against a deployment environment are:

• Compute flavour that is not supported by underlying VIDNFV Infrastructure.
• The requirement for SR-IOV PCIe Pass through to a specific Network Interface Card that might not be available.

This proposal will add dynamic checks within SDC against a registry that contains deployment environment criteria. Both standard static criteria and specific deployment environment criteria will be configurable.

(2) Industry standard certification program repositories such as the OVP portal or third-party repositories can be checked in order to minimize or even remove the need for local testing.

This proposal will add dynamic checks within SDC against a registry that contains prior certifications.

Other Options Considered

It has been considered that this these compliant checks can be carried out offline but this will be restrictive in the following way:

• it It is a big overhead to carry out those checks offline especially as VID deployments might vary from one instance of ONAP to another and hence the compliance criteria will change..
• Integrating it into SDC will allow us to connect to VTP or third-party repositories to perform deployment environment checks.
• Integrating The potential of integrating it into SDC will allow us to connect to industry standard certification programs program repositories such as OVP or third-party repositories to perform extra checks before onboarding which will minimize the local tests required (or even be skipped completely)perform certification checks.
• Integrating it into SDC will allow for better integration with CI/CD tools and automate the compliance checks especially when rolling out VNFs VNF updates.

Code Structure

ONAP code can be found in: https://git.onap.org/

...

From a high-level perspective, the proposal will allow VSP, when uploaded into SDC, to go through a set of checks to make sure it is compliant to ONAP platform in general and to the deployed VID in specific deployment environment. Figure 1 below shows the proposal in a high-level view. 

...

The check itself can be done by intruding introducing a compliance criteria "registry" will  to be consulted during the VSP validation stage. The validation block sends all passed metadata to the registry and gets the result of compliance checks back. The result of the compliance checks will determine if the VSP needs to be rejected or to be submitted to testing.

...

Figure 2: ONAP Component interaction with the proposed registry.

Metadata Tags

...

Ideally, we We need an agreed list of the metadata tags , certainly a mandatory set and secondly a plus a list of the values those tags can take . Unless we get both then the whole system is problematic.in order to effect compliance checks.

Tags Mandatory tags should include the ETSI NFV SOL/IFA SOL1 data items in the VNFD – if ETSI says some of these are optional and we think they should be mandatory then we should say so. Also the values those tags can take – again as much standardisation as we can get would be good.

Secondly, tags should (as the wiki indicates) provide pertinent details to enable the correct compute environment to be allocated again the tags and possible values should be specified.

I think a third set of tags should also be provided providing some indication of what the VNF is. E.g. if the VNF is part of the mobile network then it should be identified as one (or more) 3GPP functional entities (PDN-GW, UPF, etc., etc.) this would enable the operator to automatically identify what it does and enable the first pass automatic test of the functionality. (so vendor pushes a new MME version to the operator portal, automation sees the new update, identifies the VNF, we know what it is from the tag and what we (as an operator want it to do – we do not necessarily want to use all of the 3GPP functionality), we can then create the correct test environment (what traffic sources and destinations, signalling etc. do we use) and then run through an automated test script covering all the acceptance tests (all the required signalling messages, logging output, traffic etc.) and only if this all passes is the operator alerted that an updated VNF is ready for rollout. Any failure results in a report to the operator and also to the vendor. This process should be fully automated – no personal involvement once it is set up.

References

Links to any additional resources referenced in or related to this proposal.

...