Page History

tosca.datatypes.asd.networkInterfaceRequirements:mode (802.1Q or other). 
    derived_from: tosca.datatypes.Root  
    version: 0.1
    When operating in "trunk mode", the Cp is capable of carrying traffic for several VLANs. description: "Describes the datatype for network interface requirements"
    properties:
      trunk_mode:
        description: Absence>
 of this property implies that trunkMode is not configured for the Cp i.e. 
 Information about whether the CP instantiated from this Cp is 
    It is equivalent to boolean value "false".
        required: false
in Trunk       type: boolean
      ipam:mode (802.1Q or other). When operating in "trunk mode", 
        description: >
         the  Cp  is Thecapable defaultof value ("infraProvided") means that the CNI specifies how IPAM is done and assigns 
carrying traffic for several VLANs. 
               Absence of this property implies that trunkMode the IP address tois not configured 
               for the podCp interface. i.e. It is equivalent to boolean value "false".
        required required: falsetrue
        type: stringboolean
        constraintsdefault: false
      ipam: 
       - valid_valuesdescription: ["infraProvided", "orchestrated", "userManaged"]
> 
            interfaceType:
  Identifies whether application expects IP address assignment description:to >be 
             This attribute is applicable for passthrough andmanaged memifby interfaces.the 
cluster infrastructure (CNI IPAM plugin), or 
       The default value is ”kernel.netdev”.​ 
   configured  by   required: false
       orchestrator via for example helm input parameter, 
              or if IP assignment is handled by the application itself.
        required: true
        type: string
        constraints:
          - valid_values: ["kernel.netdevinfraProvided", "direct.userdriverorchestrated", "direct.kerneldriver", "direct.bond", "userspace"]
userManaged"]
        default: "infraProvided"
      interfaceOptioninterface_type:
        description: > 
             ThisIndicates attributewhat istype applicableof fornetwork passthroughinterface andthe memifapplication interfacesexpects.
 
           Kernel based Thevirtual defaultnetdev valuebased is ”kernel.netdev”.​ 
        required: falseon CNIs such as ovs | bridge | 
        type: list
   macvlan | ipvlan, or PCIe entry_schema:
dev directly visible in application  
        type: string
   namespace with kernel or userspace driver or bonded with the Bond constraints:
            CNI, or     userspace-CNI valid_values: [“virtio", "memif“]
     interfaceRedundancy:based network interface 
        description: > 
     (requires DPDK-OVS/VPP vSwitch).
         Default required: valuetrue
 is "infra-provided”, which means that the infrastructure is expected to provide 
        type: string
        constraints:
          - network redundancy for the pod interface. Value "none" means that the application has no 
       valid_values: ["kernel.netdev", "direct.userdriver", "direct.kerneldriver", "direct.bond", "userspace"]
        default: "kernel.netdev"
      interface_option:
      requirement on networkdescription: redundancy.> Value
 ”matedPair” means  that  the  Pod  asks  forThis aattribute mateddescribes pairverified 
realization options for the 
         of non-redundant left/right network attachmentsinterface (typically SRIOV) and handles redundancy on in question. Currently listed options 
            (virtio applicationand level.memif) Theare sameapplicable setfor ofthe networks shall be configured on both interfaces. interfaceType “userspace”.
        required: false
        type: stringlist
        constraintsentry_schema:
          - valid_values: ["infraProvided", "actPassBond", "actActBond", "actPassL3", "actActL3", "Left", "Right"] 
     nicOptions    type: string
              constraints:
        description: > 
             nics a direct user space driver the application is verified to work with. Allowed values from ETSI registry.​ 
 - valid_values: [“virtio", "memif“]
     interface_redundancy:
        description: > 
         required:  false
  Identifies switch-plane redundancy method the application  type:uses, list
        entry_schema:
     and that node infrastructure is required to comply with.
 type: string 

paramMappings:
    version: 1.0
    description: "DescribesinfraProvided", the“left” datatypeand for“right”: parameterThe mapping"
container sees a  properties:
      ipAddressParameter:
        description: >
single  vNIC  that  a)  the  infrastructure  bonds  Whenover present,both thisswitchplanes attribute
 specifies the name of the deployment artifact input parameter 
   or b) that is connected to the network via only left throughor which
 the orchestrator can configure the IP address(es), ipv4 and/or IPv6, for this 
right the switchplane.
            asdExtCpd. The paramother namecases andare providedfor IPa addressmated valuepair willof bevnics passedconnecting to the deployment 
             same toolnetwork, whenbut deployingwhere theone DeploymentArtifacts.vNIC connects
        required: false
        type: string
    via left nadName:switch 
plane and the other via right switch plane, description:
 >
              These attributes specifies, for anand asdExtCpdwhere respesentingthe aapplication secondarymanages networkthe interface,redundancy. 
             "activePassiveBond": the name(s) of the deployment artifact input parameters through which the orchestrator 
application bonds with move of MAC address. 
             "activeActiveBond“: bonded left/right links must canbe configurepart theof correspondinga networkmulti-chassis annotationLAG in
 the pod manifest with references 
       "activePassiveL3": application will move application IP address tobetween the NAD(s) to be used for creating the network interface.It is expected that the NADs 
              themselves have been created prior to the deployment of the deployment artifacts. 
        required: false
        type: string
      nadNamespace: 
        description: >
              These attributes specifies, for an asdExtCpd respesenting a secondary network interface,  vNICs.
             "activeActiveL3": the application uses anycast/ECMP.
        required: true
        type: string
        constraints:
          - valid_values: ["infraProvided", "actPassBond", "actActBond", "actPassL3", "actActL3", "Left", "Right"] 
        default: "infraProvided"
      nic_options:
        description: > 
             Identifies for the direct.userdriver interface type, the physical 
             nics the driver is verified to work with.
             Allowed values for nic types must be handled via a registry or be standardized.
        required: false
        type: list
        entry_schema:
              type: string 

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.
              Note: 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.LBIP". 
        required: false
        type: string
      external_IPs:
        description: >
              When present, this attribute specifies the name of the deployment 
              artifact input parameter through which the orchestrator can 
              configure the extermalIPs parameter of the K8s service or ingress 
              controller, or the pod network interface annotation, that the 
              extCpdData represents.
              Note: 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.extIP". 
        required: false
        type: list
        entry_schema:
           type: string
      nad_names: 
        description: >
              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.nadName".
              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.
              The application uses the mated pair of network interfaces as a single 
              logical “swith-path-redundant” network interface – and this is represented 
              by a single extCpdData. 
              Also there is a case where a third “bond” attachment interface is used in 
              the pod, bonding the two direct interfaces so that the application do not 
              need to handle the redundancy issues – application just uses the bond interface.
              In this case, all three attachments are together making up a logical 
              “switch-path-redundant” network interface represented by a single extCpdData. 
              When three NADs are used in the extCpdData the NAD implementing the bond attachment 
              interface is provided through the parameter indicated in the third place in 
              the nadNames attribute.
        required: false
        type: list
        entry_schema:
           type: string
      nad_namespace: 
        description: >
              Specifies, for an extCpdData respesenting a secondary network interface,
              the name of the deployment artifact input parameter through which the orchestrator 
              can provide the namespace where the NetworkAttachmentDefinitions (NADs) are located.
              Attribute may be omitted if the namespace is same as the application 
              namespace.
              Note: 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.NameSpace". 
        required: false
        type: string 

tosca.datatypes.asd.enhancedClusterCapabilities:
    version: 0.1
    derived_from: tosca.datatypes.Root 
    description: "Describes the datatype for parameter mapping"
    properties:
      min_kernel_version:
        description: >
               Describes the minimal required Kernel version, e.g. 4.15.0. 
               Coded as displayed by linux command uname –r
        required: true
     the name(s) of thetype: deploymentstring artifact input
 parameters through  which the orchestrator 
  required_kernel_modules:
        description: > 
           can  configureRequired thekernel correspondingmodules networkare annotationcoded inas thelisted podby manifestlinux withlsmod referencescommand, 
             e.g.  to the NAD(s) to be used for creating the network interface.It is expected that the NADs 
  ip6_tables, cryptd, nf_nat etc.​ 
        required: false
        type: list
        entry_schema:
    themselves have been created prior to the deployment of the deploymenttype: artifacts.string 
        required: false
    conflicting_kernel_modules:
        description: > 
       type: string 

enhancedClusterCapabilities:
    version: 1.0
    description: "Describes the datatype for parameter mapping"
    properties:
      minKernelVersion:
        description: "Describes the minimal required Kernel version, e.g. 4.15.0. Coded as displayed by linux command uname –r"
       Kernel modules, which must not be present in the target environment. 
             The kernel modules are coded as listed by linux lsmod command, 
             e.g.,  required: true
  ip6_tables, cryptd, nf_nat etc. 
      type: string  
      requiredKernelModulesExample:
 Linux kernel SCTP module, which would conflict description: >with use of 
             Required kernel modules are coded as listed byproprietary linuxuser lsmodspace command, e.g. ip6_tables, cryptd, nf_nat etcSCTP stack provided by the application.​ 
        required: false
        type: list
        entry_schema:
              type: string   
       conflictingKernelModulesrequired_custom_resources:
        description: > 
              Kernel modules, which must not be present in the target environment. 
             The kernel modules are coded as listed by linux lsmod command, e.g. ip6_tables, cryptd, nf_nat etc. 
     List the custom resource kinds required to be supported in the target 
        Example: Linux kernel SCTP module,environment. whichThe wouldlist conflictshall withinclude usethose ofcustom proprietaryresource userkinds spacewhich 
            are SCTPnot stackdelivered providedwith by the application.​			 
        required: false
        type: list
        entry_schema:
              type: string   
 tosca.datatypes.asd.customResourceRequirement
     requiredCustomResources cluster_labels:
        description: >  
             
This attribute allows to associate arbitrary       List the custom resource kinds required to be supported in the target environment. labels to clusters.
            The listThese shallcan includeindicate thosespecial custominfrastructure resource kinds which are not delivered with the application.			 
        required: false
capabilities (e.g., NW acceleration, 
             GPU compute,  type: list
        entry_schema:
   etc.). The intent of these labels is to serve as a set of 
           type: tosca.datatypes.asd.CustomResourceRequirement
        tosca.datatypes.asd.CustomResourceRequirement:
            derived_from: tosca.datatypes.Root
 values that can help in application placement decisions. 
             clusterLabels follow the Kubernetes label key-value-nomenclature 
             description: >(https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/). 
             It is recommended that labels follow a kind: "Redis", apiVersion: "kubedb.com/v1alpha1"
    standardized meaning e.g. for node 
        properties:
     features (https://kubernetes-sigs.github.io/node-feature-discovery/v0.9/get-started/features.html#table-of-contents).
             kindExample: 
               ClusterLabels
         type: string
     - feature.node.kubernetes.io/cpu-cpuid.AESNI: true               
         required: truefalse
        type: list
          apiVersionentry_schema:
              type: string
      required_plugin:
     type:  string
 description: a list of the name of the required K8s plugin
        required: false
        requiredtype: truelist
      clusterLabels:
        description: > entry_schema:
             This attribute allows to associate arbitrary labels to clusters.type: tosca.datatypes.asd.requiredPlugin

tosca.datatypes.asd.customResourceRequirement: 
         version: 0.1
    These can indicate special infrastructure capabilities (e.g., NW acceleration, GPGPU compute, etc.). 
derived_from: tosca.datatypes.Root 
       description: > 
           kind: "Redis",  The intent of these labels is to serve as a set of values that can help in application placement decisions. apiVersion: "kubedb.com/v1alpha1" 
       properties: 
           kind:
              Thisdescription: can"the bename specifiedof withthe thecustom attributeresource requirement"
              type: string 
    -m:  Mandatory, means deployment is not attempted if such supportrequired: istrue not
 available in the target system
      api_version:
         -p: As preference - it meansdescription: orchestrator"the willapi tryversion toof selectthe acustom systemresource withrequirement"
 specific requirements,  
          type: string 
           but if not foundrequired: true 

tosca.datatypes.asd.requiredPlugin: 
       version: 0.1
       derived_from: tosca.datatypes.Root it will attempt deployment in a system not having such HW.  
        required: false
       description: "the required type:K8s listplugin"
       properties: entry_schema:
           name:
   type: string   
      requiredPodAnnotations:
   description: "the name of the description:required >K8s plugin"
              Annotations required to be supported.
             Example that list requirement for Kubernetes cluster infrastructure support for the Multus network attachment annotations:type: string 
              required: true 
           version:
   requiredPodAnnotations: {"k8s.v1.cncf.io/networks", ... } 
        required: false
              description: "the version of the required K8s plugin"
    type: list
        entry_schema:type: string 
              typerequired: string true