Page Comparison

Objective

The current implementation (Beijing) of Allotted Resources in TOSCA uses a property on the allotted resource that stores a providing service  identifier (metadata attribute) as a foreign key.  The proposal represents Allotted Resources in TOSCA using correct TOSCA syntax and semantics to define the mapping between allotted resources and their providing [infrastructure] services. 

...

# Node type for the Providing Service 
# - Defined in the providing service TOSCA model (with a substitution mapping)
# - Defines a Provider capability, which identifies it as an allotted producer.
# - Otherwise is a typical ONAP service, with node templates for VNFs, VLs, and
#   possibly other Allotted Resources that it uses itself.
provider.service.MyProviderService:  
    derived_from:  onap.nodes.Service
    properties:
      # left out for brevity
    attributes:
      # left out for brevity
    capabilities:
      allotted_resource_provider:
        type: onap.capabilities.AllottedResourceProvider
        valid_source_types: [provider.resource.MyAllottedResource]
    interfaces:
      # left out for brevity

...

node_templates:
    # Direct usage of a my_allotted resource
    allotted_resource:
      type: provider.resource.MyAllottedResource:        properties:
         # Property values for this allotted resource instance

    # Other resource nodes (VNFs, VLs, etc.)
    other_vnf:
      type: provider.resource.my_vnf
    ...

...

1. The LCM interfaces of the allotted resource type contain the code logic for interacting with the appropriate controller that manages the providing service.  Since this is custom to each allotted resource/controller, it cannot simply be derived from the requirements and capabilities in the model.
2. The consuming service does not require knowledge of the Provider service.  It simply declares a node template of the allotted resource type.  The linkages to the Provider (including the Provider requirement) are encapsulated within the allotted resource node type definition.
3. When homing an allotted resource, SNIRO/OOF can determine the providing service type from the “AllottedResourceProvider” requirement on the allotted resource node, and search inventory for service nodes of that node type.  Alternatively, if capabilities are captured in AAI, SNIRO/OOF can search directly for service-instance nodes with an AllottedResourceProvider capability with the desired allotted resource as a valid source type.
4. Infrastructure services (i.e., allotted resource providers) can be composed of PNFs as well as VNFs for producing allotted resources.  However, this would also be encapsulated within the model of the allotted resource/provider service pair and is transparent to the consuming service.

  # Node type for the Providing Service

  # - Defined in the providing service TOSCA model (with a substitution mapping)

  # - Defines a Provider capability, which identifies it as an allotted producer.

  # - Otherwise is a typical ONAP service, with node templates for VNFs, VLs, and

  #   possibly other Allotted Resources that it uses itself.

  provider.service.MyProviderService: 

    derived_from:  onap.nodes.Service

    properties:

      # left out for brevity

    attributes:

      # left out for brevity

    capabilities:

      allotted_resource_provider:

        type:  onap.capabilities.AllottedResourceProvider

        valid_source_types: [provider.resource.MyAllottedResource]

    interfaces:

      # left out for brevity