...
These definitions are included into both the providing and the consuming services.
Core DM Types
Node type onap.nodes.NetworkFunction
Capability type onap.capabilities,AllottedResorceProvider
Relationship type onap.relationships.AllottedBy
Imaginary Types made up for this example
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
node_types:
onap.examples.nodes.Firewall:
derived_from: toscaonap.nodes.RootNetworkFunction
description: an abstract firewall
capabilities:
i_can_be_a_firewall:
type: onap.examples.capabilities.Firewall |
...
The "Interface node type" for this service
According to the Service Model Principles, any service definition will include a node type derived from onap.nodes.Service. This is a general ONAP service modeling convention rather than something specific for AR providing services. Just to remind - this type may be later use to create nodes of embedded services in a higher-order topology.
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
node_types:
vendorXXX.nodes.MyVerySpecialFirewall:
derived_from: onap.examples.nodes.Firewall
capabilities:
i_can_be_a_firewall:
type: vendorXXX.capabilities.Firewall
requirements:
i_can_provide_firewalls: - provider_service
node: vendorXXX.nodes.FirewallsProvidingService
type capability: vendorXXX.capabilities.FirewallsProvider
relationship: onap.relationships.AllottedBy
properties:
# extra props
interfaces:
Standard:
create: my_creation_script.sh # AR creation logic
delete: my_delete_script.sh |
The example above shows one of the possible ways to implement a node type, through implementation script artifacts. These scripts may include a special logic that communicates to a "factory" node inside the service. In this example, the capability of being a firewall and the capability of providing firewall are combined in one node. More elaborate designs may separate these functionalities and have a dedicated node for each of them.
All other TOSCA ways to implement an abstract node are also valid. Foe For example, a vendor may choose to have an implementing (substituting) topology for this node type.
Providing service topology
Service Model Principles stipulate that any ONAP service definition includes, besides the "interface" node type, the implementing topology. The AR services are no exception of this principle.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
topology_template: node_templates: # the provider service topology captures the guts of my_firewallwhat's required to be instantiated in order # to be prepared to allot, e.g., the allotted firewall network functions some_vnf: type: some.concrete.type.which.forms.the.internals.of.the.provider.service possibly_some_other_vnf: type: vendorXXX.nodes.MyVerySpecialFirewallalso.some.concrete.type.which.forms.the.internals.of.the.provider.service substitution_mappings: type: vendorXXX.nodes.FirewallsProvidingService capabilities: i_can_provide_firewalls: [my_firewall, i_can_provide_firewalls] |
...
The Consuming service definition, like any other ONAP service definition, will include an "interface node type". Its details are irrelevant for this example.
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
node_types:
onap.examples.nodes.FirewallShare:
derived_from: onap.examples.nodes.Firewall
description: an abstract firewall as AR
requirements:
- i_need_a_providing_service:
capability: onap.capabilities.AllottedResourceProvider
topology_template:
node_templates:
# A more releasedunconstrained abstraction of a firewall, can be implemented by any way including an allotted resource
firewall_1:
type: onap.examples.nodes.Firewall
# A more restricted abstraction - must be resolved by an allotted resource
firewall_2:
type: onap.examples.nodes.FirewallShare
# service designer specifies the exact allotted firewall
firewall_3:
type: vendorXXX.nodes.MyVerySpecialFirewall
|
TODO: add a section on the orchestration logic