...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
tosca.datatypes.asd.paramMappings:
version: 0.1
derived_from: tosca.datatypes.Root
description: "Describes the datatype for parameter mapping"
properties:
loadbalancer_IP:
description: >
When present, this attribute specifies the name of the deployment
artifact input parameter through which the orchestrator can
configure the loadbalancerIP parameter of the K8s service
or ingress controller that the extCpdData represents.
required: false typeNote: stringThe format of the Content strings is external_IPs:specific for each different
description: > orchestration templating technology used When present, this attribute specifies the name of the deployment(Helm, Teraform, etc.).
Currently only a format for use with artifactHelm inputcharts parameteris throughsuggested:
which the orchestrator can "helmchartname:[<subchartname>.]^(0..N)[<parentparamname>.]^(0..N)[<paramname>]”.
configure the extermalIPs parameter of the K8sWhether servicethe oroptional ingressparts of the format are present depends on how the
controller, or the pod network interface annotation, that the parameter is declared in the helm chart. An example is:
extCpdData represents. required: falsechartName:subChart1.subChart2.subChart3.Parent1.Parent2.Parent3.paramName.
type: list
entry_schema required: false
type: string
nadexternal_namesIPs:
description: >
Specifies, for an extCpdDataWhen respesentingpresent, athis secondaryattribute networkspecifies interface,the name of the deployment
the name(s) of the deployment artifact input parameter(s) through which the orchestrator can
the orchestrator can provideconfigure the namesextermalIPs parameter of the K8s service networkor attachmentingress
definitions (NADs)controller, or the orchestratorpod hasnetwork createdinterface asannotation, basethat for the network
interface the extCpdData represents.
Note: NoteThe 1:format Whenof the extCpdDataContent representstrings a networkRedundant/mated-pair of
is specific for each different
sriov interfaces, thereorchestration aretemplating referencestechnology toused 2 or 3 related NADs needed(Helm, Teraform, etc.).
Currently only a toformat befor passed,use whilewith forHelm othercharts interfaceis typessuggested:
only one NAD reference "helmchartname:[<subchartname>.]^(0..N)[<parentparamname>.]^(0..N)[<paramname>]”.
is needed to be passed. Whether the optional parts of the format are present depends on how the
Note 2: The format of the Content strings is specific forparameter eachis differentdeclared in the helm chart. An example is:
orchestration templating technology used (Helm, Teraform, etc.) chartName:subChart1.subChart2.subChart3.Parent1.Parent2.Parent3.paramName.
required: false
Currently only a format fortype: uselist
with Helm charts is suggested:
entry_schema:
type: string
nad_names:
description: >
"helmchartname:[<subchartname>.]^(0..N)[<parentparamname>.]^(0..N)[<paramname>]”.
Note 3: Whether the optional parts of the format are present depends on how the
parameter is declared in the helm chart. An example is:
Specifies, for an extCpdData respesenting a secondary network interface,
the name(s) of the deployment artifact input parameter(s) through which
the orchestrator can provide the names of the network attachment
definitions (NADs) the orchestrator has created as base for the network
interface the extCpdData represents.
Note 1: When the extCpdData represent a networkRedundant/mated-pair of
sriov interfaces, there are references to 2 or 3 related NADs needed
to be passed, while for other interface types only one NAD reference
is needed to be passed.
Note 2: The format of the Content strings is specific for each different
orchestration templating technology used (Helm, Teraform, etc.).
Currently only a format for use with Helm charts is suggested:
"helmchartname:[<subchartname>.]^(0..N)[<parentparamname>.]^(0..N)[<paramname>]”.
Whether the optional parts of the format are present depends on how the
parameter is declared in the helm chart. An example is:
chartName:subChart1.subChart2.subChart3.Parent1.Parent2.Parent3.paramName.
Note 3: A direct attached (passthrough) network interface, such as an sriov
interface, attaches to a network via only one of the two switch planes
in the infrastructure.
When using a direct attached network interface one therefore commonly in a
pod uses a mated pair of sriov network attachments, where each interface
attaches same network but via different switchplane.
chartName:subChart1.subChart2.subChart3.Parent1.Parent2.Parent3.paramName. The application uses the mated pair of network interfaces Aas directa attachedsingle (passthrough)
network interface, such as an sriov logical “swith-path-redundant” network interface – and this interface,is attachesrepresented to
a network via only one of the two switch planes by a single extCpdData.
in the infrastructure. Also there is a case where a third “bond” Whenattachment usinginterface ais directused attachedin network
interface one therefore commonly in a the pod, bonding the two direct interfaces podso usesthat athe matedapplication pairdo ofnot sriov
network attachments, where each interface need to handle the redundancy issues attaches– sameapplication networkjust butuses viathe differentbond switchplaneinterface.
TheIn applicationthis usescase, theall matedthree pairattachments ofare networktogether interfacesmaking asup a singlelogical
logical “swith“switch-path-redundant” network interface – and this is represented represented by a single extCpdData.
When three NADs are byused ain singlethe extCpdData. the NAD implementing the bond attachment
Also there is a case where ainterface thirdis “bond”provided attachmentthrough interfacethe isparameter usedindicated in the third place in
the pod, bonding the twonadNames directattribute.
interfaces so that the application dorequired: notfalse
type: list
needentry_schema:
to handle the redundancy issues – application just uses the bond interface. type: string
nad_namespace:
In this case,description: all>
three attachments are together making up a logical Specifies, for an extCpdData respesenting a secondary network interface,
“switch-path-redundant” network interface represented by a single extCpdData.
the name of the deployment artifact input parameter through which the orchestrator
When three NADs are used in thecan extCpdDataprovide the NADnamespace implementingwhere the bond attachment NetworkAttachmentDefinitions (NADs) are located.
Attribute interfacemay isbe providedomitted throughif the parameternamespace is indicatedsame inas the thirdapplication place
in namespace.
the nadNames attribute. required: false Note: The type:format listof the Content strings is specific for each different entry_schema:
type: string orchestration templating nad_namespace:
technology used (Helm, Teraform, etc.).
description: > Currently Specifies,only fora anformat extCpdDatafor respesentinguse awith secondaryHelm networkcharts interface,is suggested:
the name of the deployment artifact input parameter through which the orchestrator "helmchartname:[<subchartname>.]^(0..N)[<parentparamname>.]^(0..N)[<paramname>]”.
Whether the optional parts of the format canare providepresent thedepends namespaceon wherehow the NetworkAttachmentDefinitions
(NADs) are located. parameter is declared Attributein maythe behelm omittedchart. ifAn theexample namespace is: same
as the application namespace.chartName:subChart1.subChart2.subChart3.Parent1.Parent2.Parent3.paramName.
required: false
type: string |
...