Artifact Properties Use cases and Examples to demonstrate the need of artifact properties July 2018

VNF CSAR On-boarding On-boarding refers to the process of Creating a VNF CSAR and its content Submitting the VNF CSAR to the NFV Orchestrator to be included in the catalogue CSARs making their way to Orchestrator What Orchestrator does upon package reception. 1. Onboard CSAR Artifact Processor1 VNF CSAR NFV Orchestrator Artifact Processor2 2. Verify CSAR integrity 3. Onboard CSAR NFV Catalogue 6. Distribute artifacts to artifact processors 4,5 Parse TOSCA service templates, validate CSAR content VNF CSAR 1 Artifact Processor3 VNF CSAR 2 VNF CSAR 3

VNF CSAR On-boarding – How and Why How is on-boarding done Request for uploading a VNF CSAR is received by the NFV Orchestrator NFV Orchestrator verifies integrity of package NFV Orchestrator re-directs request with VNF CSAR to NFV Catalogue NFV Catalogue receives VNF CSAR and reads VNF Package content NFV Catalogue validates the VNF CSAR NFV Orchestrator distributes artifacts to artifact processors from NFV Catalogue Why is on-boarding needed Eases deployment of VNFs and VNF Managers Promotes inter operable components within the NFV domain Validate and detect errors early , prior to VNF deployment Reduces time for first instantiation of VNF

Artifact Distribution Artifact distribution to artifact processors through the following mechanisms: Synchronous on-boarding: During onboarding, forcefully push artifacts to artifacts processor and wait for success response, do not mark onboarding operation as successful until a success response is received. Asynchronous on-boarding: Notify artifact processors and let artifact processors pull artifacts instead of pushing Do not distribute artifacts during onboarding, let artifact processors pull them from CSAR catalogue when they are called to execute the artifact Drawback: Disables artifact validation during onboarding, opens up possibilities of failures during deployment of CSAR in to the cloud

Use case: VNF Image Onboarding – Uploading image to image repository In the case of VNF image onboarding, VIM plays the role of artifact processor Different VIMs have different metadata that describe the VNF image Openstack (Glance) disk_format, container_format, min_disk, min_ram,file, checksum , file etc. Vmware vmware_disktype, vmware_ostype etc. OpenshiftContainer name, namespace, selfLink ,resourceVersion etc. Orchestrator shall ensure that the image gets into the VIM/ image repository before starting the deployment of service template Describing the artifact properties as meta data implies identification of exhaustive set of artifact meta data for different VIMs. These image characteristics are best described as artifact properties in TOSCA.

Use case : Node with many artifact types Consider a node with many artifacts types , certain properties of the artifact are needed to be processed by the Orchestrator for delegating to the appropriate artifact processor Cannot correlate the properties to the corresponding artifact if these properties are moved to the node Example: Different Artifact Types for different lifecycle operations of Node (create, terminate ,configure, etc.) dbServer:    type: tosca.nodes.nfv.VDU    properties:     name: sprout     description:      artifacts:       - sw_image:              type: tosca.artifacts.nfv.SwImage             file: http://1.1.1.1/images/ubuntu-14.04.qcow2             properties:              name: ubuntu-14.04              version: 14.04             checksum: e5c1e205f62f3      - configuration:           type: tosca.artifacts.Implementation.Ansible          file: implementation/configuration/Ansible/configure.yml         properties:           ansible_version: 1.1.1     - terminate:          type: tosca.artifacts.Implementation.scripts          file: implementation/configuration/scripts/terminate.sh        properties:          version: 6.2

What the Orchestrator could do with artifact properties? 1. Orchestrator could check for the version property and use this information for handing off to the correct version of artifact processor 2. Orchestrator could use the checksum property to verify if the integrity of artifact is retained (i.e. successful transfer) after copying the artifact to the artifact processor 3. Orchestrator could try to locate the artifact processor based on the artifact type and if not found, try to install the artifact processor and its licenses using certain artifact properties 4. Orchestrator could use artifact properties  to invoke appropriate package manager for installing an artifact 5. Orchestrator could configure access rights for artifacts after transfer to artifact processor

Summary Artifact properties are required to address cases where a node can be associated with several artifacts. Moving these properties to the containing node does not help in correlating a property to the corresponding artifact Artifact properties are required during VNF “On-boarding”, different properties could be associated with the VNF image depending on the VIM configuration Critical to maintain backward compatibility with TOSCA Simple Profile specifications v1.2. Has huge re-implementation costs for products based on the above use cases

Views of TOSCA Simple Profile WG so far.. The problem is with associating properties with Artifacts. The artifact definition grammar in TOSCA does not allow properties (see Section 3.5.6.1 in Version 1.1 of the spec). The reason for this is that there is no mechanism in TOSCA currently to use such properties even if they were allowed. There are three ways in which property values can affect how services get orchestrated:   By serving as inputs into Interface operations. This can be done using the get_property or get_attribute functions, but those functions only retrieve properties from node templates, relationship templates, or capabilities By directing the orchestrator for how dangling requirements need to be fulfilled from an active inventory. This can be done by specifying property values in node filters, but node filters only use properties from node templates, relationship templates, or capabilities. By driving the substitution mappings process. Again, artifacts don’t get involved in substitution mappings. In summary, even if we allowed properties in artifacts, there is nothing an orchestrator could do with those artifacts.  There is a glaring inconsistency in the spec, since Artifact Type definitions do allow properties. Since artifact definitions themselves are not able to assign values to properties defined in an Artifact Type, this needs to get fixed.