Using the CCI elements in VMware Aria Automation templates

You can add Cloud Consumption Interface (CCI) elements to use the CCI service within a VMware Aria Automation template so that your users can request Kubernetes-based workloads using the Virtual Machine service and Tanzu Kubernetes Grid service within a supervisor namespace.

To see the CCI elements, expand the Cloud Consumption Interface section within the resource library in your cloud template or type cci in the Search resource types field.

Locate the CCI elements in your cloud template

The table below shows the three types of CCI resources that are available in the template for users to drag, drop and configure.

Supervisor Namespace resource `CCI.Supervisor.Namespace`	Create a new Supervisor Namespace, that provides a Kubernetes-based workspace with resource limits, user access, and available Supervisor services, so that users can provision VM and TKG resources based on application needs.
Supervisor resource `CCI.Supervisor.Resource`	Create any supported Supervisor Kubernetes resource within a Supervisor Namespace, such as `virtualmachines`, `virtualmachineservices`, `tanzukubernetesclusters`, `persistentvolumeclaims`, `secrets`, and so on, depending on the Kubernetes manifest passed to the Supervisor resource that is being configured.
TKG resource `CCI.TKG.Resource`	Create any supported Kubernetes resource within a TKG cluster.

Note: Before you can add CCI elements to your cloud template, a VMware Aria Automation administrator must set up CCI first. See Cloud Consumption Interface setup and configuration.

The following examples show how the CCI resources appear in the YAML code of your cloud template. Each example is pruned to show only the important lines.

Supervisor Namespace Resource example

CCI.Supervisor.Namespace represents the Supervisor Kubernetes-based workspace where the user-managed vSphere Supervisor IaaS resources for the application are created.

This example defines a CCI supervisor namespace resource named cciNamespace to provision a Supervisor Namespace called demo.

To ensure that the namespace is provisioned on a targeted Supervisor, you must configure the Supervisor Namespace with a project-defined className and regionName.

formatVersion: 1
inputs: {}
resources:
  cciNamespace:
    type: CCI.Supervisor.Namespace
    properties:
      name: demo
      className: default
      regionName: dev-us-west

Supervisor Resource example

You use CCI.Supervisor.Resource to pass the Kubernetes manifest for Kubernetes objects supported to run within a supervisor namespace context.

To provision the supervisor resource within a particular supervisor namespace, you configure the supervisor resource context property by mapping it to the Supervisor Namespace ID using a template bind expression, for example context: ${resource.cciNamespace.id}.
To specify the objects to provision, you configure the manifest property of the Supervisor Resource by passing the Kubernetes manifest to the Kubernetes object that you are creating.

This example creates a TKG cluster by providing a Kubernetes manifest that specifies the network, topology, control plane size, and worker node count among other settings.

formatVersion: 1
inputs: {}
resources:
  cciTKGCluster:
    type: CCI.Supervisor.Resource
    properties:
      context: ${resource.cciNamespace.id}
      manifest:
        apiVersion: cluster.x-k8s.io/v1beta1
        kind: Cluster
        metadata:
          name: ${input.tkg_Name}
          labels:
            tkg-cluster-selector: ${input.tkg_Name}
        spec:
          clusterNetwork:
            cni:
              name: antrea
            pods:
              cidrBlocks:
                - 192.168.156.0/20
            services:
              cidrBlocks:
                - 10.96.0.0/12
            serviceDomain: cluster.local
          topology:
            class: tanzukubernetescluster
            version: v1.24.9---vmware.1-tkg.4
            variables:
              - name: storageClasses
                value:
                  - tmm-kubernetes-storage-policy
              - name: defaultStorageClass
                value: tmm-kubernetes-storage-policy
              - name: vmClass
                value: ${input.controlPlaneVmClassName}
              - name: storageClass
                value: tmm-kubernetes-storage-policy
            controlPlane:
              replicas: ${input.controlPlaneCount}
              metadata:
                annotations:
                  run.tanzu.vmware.com/resolve-os-image: os-name=photon
            workers:
              machineDeployments:
                - class: node-pool
                  name: ${input.tkg_Name}-nodepool
                  replicas: ${input.workerCount}
                  metadata:
                    annotations:
                      run.tanzu.vmware.com/resolve-os-image: os-name=photon
                  variables:
                    overrides:
                      - name: vmClass
                        value: ${input.workerVmClassName}

This example defines a virtual machine by providing a Kubernetes manifest that defines the VM configuration and includes a wait based condition.

formatVersion: 1
inputs: {}
resources:
  vm:
    type: CCI.Supervisor.Resource
    properties:
      context: ${resource.cciNamespace.id}
      manifest:
        apiVersion: vmoperator.vmware.com/v1alpha1
        kind: VirtualMachine
        metadata:
          finalizers:
            - virtualmachine.vmoperator.vmware.com
          generation: 1
          labels:
            vm-selector: vm-2rfx
          name: vm-2rfx
        spec:
          className: best-effort-xsmall
          imageName: vmi-c3d184be88e1af1cd
          networkInterfaces:
            - networkType: nsx-t
          powerOffMode: hard
          powerState: poweredOn
          restartMode: hard
          storageClass: vsan-default-storage-policy
          suspendMode: hard
      wait:
        conditions:
          - type: VirtualMachinePrereqReady
            status: "False"
            reason: VirtualMachineImageNotReady
            indicatesFailure: true

TKG Resource example

You use CCI.TKG.Resource to create supported Kubernetes resources within a TKG cluster or within a namespace running on the TKG cluster.

To bind a TKG resource to a TKG cluster, you map the ID of the supervisor TKG Cluster resource with the context property, for example context: ${resource.cciTKGCluster.id}.
If you are creating a namespace within a TKG resource named cciTKGNamespace for example, you can bind a TKG resource to the namespace by inserting the name of the TKG resource in the context property or context: ${resource.cciTKGNamespace.id}.
The Kubernetes manifest that is passed within the resource properties specifies the type of the Kubernetes object to provision.

This example shows a secret as a TKG resource bound to a TKG cluster named cciTKGCluster.

...
  tkgSecret:
    type: CCI.TKG.Resource
    properties:
      context: ${resource.cciTKGCluster.id}
      manifest:
        apiVersion: v1
        kind: Secret
        metadata:
          name: nvaie-apikey
        type: Opaque
        data:
          username: KM9hdCCodG9rZW4=
          password: ${base64_encode(input.password)}
...

Adding a wait property

Both the supervisor resource and the TKG resource support a wait property that will wait for specific conditions or field values within a resource, before considering the resource creation to be completed. Wait property types are:

Field Wait: List of fields where each field can be configured with a property path and a value. The value must be matched before the resource is considered completed.
Condition Wait: List of conditions that indicate success or failure of resource creation.

This example shows a wait condition added to a supervisor resource. The condition must be met before the supervisor resource can be flagged as completed.

...
    wait:
      fields:
        - path: status.loadBalancer.ingress[0].ip
          value: "*"
...