Support VNF node type mapping to SDC AID DM

VNF Mapping:

• Define a new data type based on the org.openecomp.resource.abstract.nodes.VF with ETSI SOL001 VNF data type attributes.

• • Make the org.openecomp.resource.abstract.nodes.ETSI.VNF a superset of both tosca.nodes.nfv.VNF and org.openecomp.resource.abstract.node.VF
  • During VNF onboarding, SDC copies SOL001 VNF attribute contents to the corresponding attributes in the org.openecomp.resource.abstract.nodes.ETSI.VNF
    • In Guilin, SO NFVO, VFC and SVNFM get those SOL001 VNF attributes from the descriptor, not from AAI. So, AAI schema changes are not expected in Guilin.
  • SOL001 VNF attributes in SDC AID DM VNF will be visible to SDC UI, so SDC UI can change the attributes.
    • But the onboarded vendor ETSI package will note be changed by the SDC UI users in Guilin.
    • Since SO NFVO, VFC and SVNFM use only the original ETSI package, those changes will not be used in Guilin;
    • For the Honolulu release, it is under consideration
      • to sync up between those modified SOL001 VNF attributes and the vendor ETSI Package attributes 
      • to reflect those modified SOL001 VNF attributes in the orchestration
  • ONAP specific attributes that are inherited from the org.openecomp.resource.abstract.nodes.VF will be filled up by SDC (design time)
    • Those attribute contents will not be mapped back into the SOL001 VNF (reverse mapping). For that case, only the SOL001 VNF corresponding attributes will be copied