Defining Pods and Pod Elements
A Pod holds Physical or Virtual accounts. It provides support for different device categories, including compute, storage, and network. The following stages are involved in creating a new pod type using Open Automation module:
-
Create the pod definition XML configuration file in the /<Open_Automation>/pod definition directory where <Open_Automation> is the module project. More details are provided later in this section. Refer also to
foo.xml
in the samples provided with the Open Automation SDK. -
Upon deploying the module, the pod definition configuration file is copied to the appropriate Cisco UCS Director location for processing.
-
The new pod definition is available in the Type dropdown list of values in the Add Pod form once the module is enabled and services are restarted.
-
Customize the new pod type, as appropriate. For information about customization, refer to information about Converged Stack Builder in Collecting Account Inventory and elsewhere in the SDK documentation.
-
If you delete the module, the new pod type created for it (as described in the first step above) will be deleted.
Defining Pod Types and Elements - Examples
Following is a line by line explanation of a pod definition.
The "pod-definition" is the root element. The type should be a string that uniquely identifies the pod type. The label should be what is shown in the UI for this pod type. In the following example, the pod being defined is a Flex Pod:
< pod-definition type="FlexPod"label="FlexPod">
-
category specifies the device category the element belongs in 1 (compute), 2 (storage), 3 (network).
-
name is the name of device type, this is mostly for readability purposes.
-
count is the max number of this device type that can be used in one pod.
-
account-types is a comma separated string of all account type IDs that collect data for this device type.
< pod-element category="1" name="Cisco UCS" code="-1"
count="1" account-types="11">
The example above shows a typical Cisco UCS pod-element. The category is 1, so it's compute category. The count is 1, so there can only be one Cisco UCS in a Flex Pod. The Cisco UCS collector has an account type ID of 11, which means it is internal. (For a list of IDs for available the available collectors, ask a lead.)
< device-model vendor="[cC]isco"version=".*"model="UCSM"/>
The device-model provides the details on how UCSD will perform pod compliance checks. The vendor, version, and model strings will be checked against the values you provided when you added the account through the UI. Note that the use of regular expressions is allowed, so in this example, if you enter "cisco" or "Cisco", it is still acceptable.
</ pod-definition >
Finally, be sure to properly close the pod-definition element.
Following is an example of a Nexus switch pod definition:
<pod-element category="3" name="NXOS" count="6" code="81" account-types="nxos">
<device-model vendor="[cC]isco" version=".*" model="Nexus[\s]*[157].*" />
</pod-element>
Here is an example of a NetApp storage device pod definition:
<pod-element category="2" count="2" code="77" account-types="12,14">
<device-model vendor="[nN]et[aA]pp" version=".*" model="FAS.*|.*Cluster.*|.*OnCommand.*|.*DFM.*" />
</pod-element>