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

2. 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

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

4. 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

5. 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.

6. 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:
            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

7. 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

8. 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

9. 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 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.