1 tosca_definitions_version: tosca_simple_yaml_1_2
2 description: ASD types definitions version 0.1
4 tosca.datatypes.asd.networkInterfaceRequirements:
5 derived_from: tosca.datatypes.Root
7 description: "Describes the datatype for network interface requirements"
11 Information about whether the CP instantiated from this Cp is
12 in Trunk mode (802.1Q or other). When operating in "trunk mode",
13 the Cp is capable of carrying traffic for several VLANs.
14 Absence of this property implies that trunkMode is not configured
15 for the Cp i.e. It is equivalent to boolean value "false".
21 Identifies whether application expects IP address assignment to be
22 managed by the cluster infrastructure (CNI IPAM plugin), or
23 configured by orchestrator via for example helm input parameter,
24 or if IP assignment is handled by the application itself.
28 - valid_values: ["infraProvided", "orchestrated", "userManaged"]
29 default: "infraProvided"
32 Indicates what type of network interface the application expects.
33 Kernel based virtual netdev based on CNIs such as ovs | bridge |
34 macvlan | ipvlan, or PCIe dev directly visible in application
35 namespace with kernel or userspace driver or bonded with the Bond
36 CNI, or userspace-CNI based network interface
37 (requires DPDK-OVS/VPP vSwitch).
41 - valid_values: ["kernel.netdev", "direct.userdriver", "direct.kerneldriver", "direct.bond", "userspace"]
42 default: "kernel.netdev"
45 This attribute describes verified realization options for the
46 network interface in question. Currently listed options
47 (virtio and memif) are applicable for the interfaceType “userspace”.
53 - valid_values: ["virtio", "memif"]
56 Identifies switch-plane redundancy method the application uses,
57 and that node infrastructure is required to comply with.
58 "infraProvided", “left” and “right”: The container sees a
59 single vNIC that a) the infrastructure bonds over both switchplanes
60 or b) that is connected to the network via only left or
61 right the switchplane.
62 The other cases are for a mated pair of vnics connecting to
63 same network, but where one vNIC connects
64 via left switch plane and the other via right switch plane,
65 and where the application manages the redundancy.
66 "activePassiveBond": the application bonds with move of MAC address.
67 "activeActiveBond“: bonded left/right links must be part of a multi-chassis LAG
68 "activePassiveL3": application will move application IP address between the vNICs.
69 "activeActiveL3": the application uses anycast/ECMP.
73 - valid_values: ["infraProvided", "actPassBond", "actActBond", "actPassL3", "actActL3", "Left", "Right"]
74 default: "infraProvided"
77 Identifies for the direct.userdriver interface type, the physical
78 nics the driver is verified to work with.
79 Allowed values for nic types must be handled via a registry or be standardized.
85 tosca.datatypes.asd.paramMappings:
87 derived_from: tosca.datatypes.Root
88 description: "Describes the datatype for parameter mapping"
92 When present, this attribute specifies the name of the deployment
93 artifact input parameter through which the orchestrator can
94 configure the loadbalancerIP parameter of the K8s service
95 or ingress controller that the extCpdData represents.
96 Note: The format of the Content strings is specific for each different
97 orchestration templating technology used (Helm, Teraform, etc.).
98 Currently only a format for use with Helm charts is suggested:
99 "<helmchartname>:[<subchartname>.]^(0..N)[<parentparamname>.]^(0..N)<paramname>".
100 Whether the optional parts of the format are present depends on how the
101 parameter is declared in the helm chart. An example is:
102 "chartName:subChart1.subChart2.subChart3.Parent1.Parent2.Parent3.LBIP".
107 When present, this attribute specifies the name of the deployment
108 artifact input parameter through which the orchestrator can
109 configure the extermalIPs parameter of the K8s service or ingress
110 controller, or the pod network interface annotation, that the
111 extCpdData represents.
112 Note: The format of the Content strings is specific for each different
113 orchestration templating technology used (Helm, Teraform, etc.).
114 Currently only a format for use with Helm charts is suggested:
115 "<helmchartname>:[<subchartname>.]^(0..N)[<parentparamname>.]^(0..N)<paramname>".
116 Whether the optional parts of the format are present depends on how the
117 parameter is declared in the helm chart. An example is:
118 "chartName:subChart1.subChart2.subChart3.Parent1.Parent2.Parent3.extIP".
125 Specifies, for an extCpdData respesenting a secondary network interface,
126 the name(s) of the deployment artifact input parameter(s) through which
127 the orchestrator can provide the names of the network attachment
128 definitions (NADs) the orchestrator has created as base for the network
129 interface the extCpdData represents.
130 Note 1: When the extCpdData represent a networkRedundant/mated-pair of
131 sriov interfaces, there are references to 2 or 3 related NADs needed
132 to be passed, while for other interface types only one NAD reference
133 is needed to be passed.
134 Note 2: The format of the Content strings is specific for each different
135 orchestration templating technology used (Helm, Teraform, etc.).
136 Currently only a format for use with Helm charts is suggested:
137 "<helmchartname>:[<subchartname>.]^(0..N)[<parentparamname>.]^(0..N)<paramname>".
138 Whether the optional parts of the format are present depends on how the
139 parameter is declared in the helm chart. An example is:
140 chartName:"subChart1.subChart2.subChart3.Parent1.Parent2.Parent3.nadName".
141 Note 3: A direct attached (passthrough) network interface, such as an sriov
142 interface, attaches to a network via only one of the two switch planes
143 in the infrastructure.
144 When using a direct attached network interface one therefore commonly in a
145 pod uses a mated pair of sriov network attachments, where each interface
146 attaches same network but via different switchplane.
147 The application uses the mated pair of network interfaces as a single
148 logical “swith-path-redundant” network interface – and this is represented
149 by a single extCpdData.
150 Also there is a case where a third “bond” attachment interface is used in
151 the pod, bonding the two direct interfaces so that the application do not
152 need to handle the redundancy issues – application just uses the bond interface.
153 In this case, all three attachments are together making up a logical
154 “switch-path-redundant” network interface represented by a single extCpdData.
155 When three NADs are used in the extCpdData the NAD implementing the bond attachment
156 interface is provided through the parameter indicated in the third place in
157 the nadNames attribute.
164 Specifies, for an extCpdData respesenting a secondary network interface,
165 the name of the deployment artifact input parameter through which the orchestrator
166 can provide the namespace where the NetworkAttachmentDefinitions (NADs) are located.
167 Attribute may be omitted if the namespace is same as the application
169 Note: The format of the Content strings is specific for each different
170 orchestration templating technology used (Helm, Teraform, etc.).
171 Currently only a format for use with Helm charts is suggested:
172 "<helmchartname>:[<subchartname>.]^(0..N)[<parentparamname>.]^(0..N)<paramname>".
173 Whether the optional parts of the format are present depends on how the
174 parameter is declared in the helm chart. An example is:
175 "chartName:subChart1.subChart2.subChart3.Parent1.Parent2.Parent3.NameSpace".
179 tosca.datatypes.asd.extCpdData:
181 derived_from: tosca.datatypes.Root
182 description: "Describes the datatype for external connection point definition data"
185 description: "The identifier of this extCpdData"
190 This property describes for a particular ExtCpd instance
191 what service it exposes.
194 virtual_link_requirement:
196 Refers in an abstract way to the network or multiple networks that
197 the ExtCpd shall be exposed on (ex: OAM, EndUser, backhaul, LI, etc)
200 network_interface_realization_requirements:
202 Details container implementation specific requirements on
203 the NetworkAttachmentDefinition
205 type: tosca.datatypes.asd.networkInterfaceRequirements
206 input_param_mappings:
208 Information on what helm chart input parameters that
209 are required to be configured for this extCpd
211 type: tosca.datatypes.asd.paramMappings
214 Kubernetes API resource name for the resource manifest for the service,
215 ingress controller or pod
219 tosca.datatypes.asd.enhancedClusterCapabilities:
221 derived_from: tosca.datatypes.Root
222 description: "Describes the datatype for parameter mapping"
226 Describes the minimal required Kernel version, e.g. 4.15.0.
227 Coded as displayed by linux command uname –r
230 required_kernel_modules:
232 Required kernel modules are coded as listed by linux lsmod command,
233 e.g. ip6_tables, cryptd, nf_nat etc.
238 conflicting_kernel_modules:
240 Kernel modules, which must not be present in the target environment.
241 The kernel modules are coded as listed by linux lsmod command,
242 e.g., ip6_tables, cryptd, nf_nat etc.
243 Example: Linux kernel SCTP module, which would conflict with use of
244 proprietary user space SCTP stack provided by the application.
249 required_custom_resources:
251 List the custom resource kinds required to be supported in the target
252 environment. The list shall include those custom resource kinds which
253 are not delivered with the application.
257 type: tosca.datatypes.asd.customResourceRequirement
260 This attribute allows to associate arbitrary labels to clusters.
261 These can indicate special infrastructure capabilities (e.g., NW acceleration,
262 GPU compute, etc.). The intent of these labels is to serve as a set of
263 values that can help in application placement decisions.
264 clusterLabels follow the Kubernetes label key-value-nomenclature
265 (https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/).
266 It is recommended that labels follow a standardized meaning e.g. for node
267 features (https://kubernetes-sigs.github.io/node-feature-discovery/v0.9/get-started/features.html#table-of-contents).
270 - feature.node.kubernetes.io/cpu-cpuid.AESNI: true
276 description: a list of the name of the required K8s plugin
280 type: tosca.datatypes.asd.requiredPlugin
282 tosca.datatypes.asd.customResourceRequirement:
284 derived_from: tosca.datatypes.Root
286 kind: "Redis", apiVersion: "kubedb.com/v1alpha1"
289 description: "the name of the custom resource requirement"
293 description: "the api version of the custom resource requirement"
297 tosca.datatypes.asd.requiredPlugin:
299 derived_from: tosca.datatypes.Root
300 description: "the required K8s plugin"
303 description: "the name of the required K8s plugin"
307 description: "the version of the required K8s plugin"
313 derived_from: tosca.nodes.Root
314 description: "The ASD node type"
320 description: Identifier of this ASD. It is in UUID format as specified in RFC 4122
321 descriptor_invariant_id:
325 Identifier of this descriptor in a version independent manner. This attribute
326 is invariant across versions of ASD. It is in UUID format as specified in RFC 4122
330 description: Identifies the version of the ASD.
334 description: Identifies the Identifies the version of this ASD’s schema.
335 function_description:
338 description: Description of the application service described by this ASD.
342 description: Identifies the provider of the ASD.
346 description: Name to identify the application service described by this ASD
350 description: Identifies the version of the application service described by this ASD.
355 type: tosca.datatypes.asd.extCpdData
357 Describes the externally exposed connection points of the application
358 service described by this ASD
359 enhanced_cluster_capabilities:
360 type: tosca.datatypes.asd.enhancedClusterCapabilities
363 A list of expected capabilities of the target Kubernetes cluster to aid
364 placement of the application service on a suitable cluster.
365 tosca.nodes.asdInNsd:
366 derived_from: tosca.nodes.nfv.VNF
367 description: "The generic ASD node types for NS requirements. Optional properties are not list here."
372 description: Identifier of an ASD. It is in UUID format as specified in RFC 4122
376 description: Identifies the version of the ASD.
381 description: Identifies the provider of the ASD
386 description: Please use the application_name property
391 description: Please use the application_version property
397 constraints: [ equal: "simple" ]
410 capability: tosca.capabilities.nfv.VirtualLinkable
411 relationship: tosca.relationships.nfv.VirtualLinkableTo
414 capability: tosca.capabilities.nfv.VirtualLinkable
415 relationship: tosca.relationships.nfv.VirtualLinkableTo
416 occurrences: [ 0,UNBOUNDED ]
418 tosca.artifacts.asd.deploymentItem:
420 derived_from: tosca.artifacts.Root
421 description: "Describes the artifact type of asd deployment item"
422 file: "URI or path of the artifact"
425 description: "The identifier of this asd deployment item"
430 Specify artifact type.
434 - valid_values: ["helm_chart", "helmfile", "crd", "terraform" ]
437 Specifies the deployment stage that the DeploymentArtifact belongs to.
438 A lower value specifies that the DeploymentArtifact belongs to an earlier
439 deployment stage. When this value is omitted, the deployment order
440 will be decided by the orchestrator.
443 lifecycle_parameters:
444 description: "list of parameters that can be overridden at deployment time "