...
| Code Block |
|---|
| title | Node type onap.examples.node.Firewall |
|---|
| linenumbers | true |
|---|
| collapse | true |
|---|
|
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 |
...
| Code Block |
|---|
| title | Firewall implementing node type |
|---|
| linenumbers | true |
|---|
| collapse | true |
|---|
|
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
typecapability: 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.
...
| Code Block |
|---|
| title | AR Providing Service Topology |
|---|
| linenumbers | true |
|---|
| collapse | true |
|---|
|
topology_template:
node_templates:
# the provider service topology captures the guts my_firewallof what'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]
|
...
| Code Block |
|---|
| title | Consuming service topology |
|---|
| linenumbers | true |
|---|
| collapse | true |
|---|
|
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
