Pod blueprint XML reference
This section describes the pod blueprint XML file tags.
addressPoolBlueprint Schema
<addressPoolBlueprint>
<defaultPublicFlag></defaultPublicFlag>
<defaultShareableFlag></defaultShareableFlag>
<name></name>
<natPoolName><natPoolName>
</addressPoolBlueprint>Description:
Each addressPoolBlueprint tag partially specifies how to create a pod level address pool. A pod level address pool is a pool that each container on the pod can acquire addresses from. The partial specification of the pool in this tag is supplemented with additional input from the user for the specific network address and network mask involved in the pod creation wizard page.
Children:
| Tag | Description |
|---|---|
defaultPublicFlag | Controls whether the pool should be initially flagged as public or not when the pod creation wizard page is presented for creating the pool (the user can override this initial value in the wizard). If a pool is flagged as private, multiple pods are allowed to reserve the same pool from IPAM, with each pod receiving its own copy. This means that given PodA and PodB, each could have its own private 10.1.1.0/26 pool. If ContainerA acquired an address from PodA's pool, it would acquire 10.1.1.1, and if ContainerB acquired an address from PodB's pool, it would also acquire 10.1.1.1. |
defaultShareableFlag | Controls whether the pool should be initially flagged as shareable or not when the pod creation wizard page is presented for creating the pool (the user can override this initial value in the wizard). If a pool is flagged as shareable, multiple pods are allowed to reserve the same pool from IPAM, with each pod sharing the same copy. This means that given PodA and PodB, each could share an 11.1.1.0/26 pool. If ContainerA acquired an address from PodA's pool, it would acquire 11.1.1.1, and if ContainerB acquired an address from PodB's pool, it would acquire 11.1.1.2. |
name | Specifies a way to uniquely identify this address pool within the pod. |
natPoolName | (Optional) Specifies the name of an address pool from which a NAT address can be acquired. Used when NIC/VIP addresses acquired from this address pool need to be translated. The NAT address pool should be a pool that is declared in the pod blueprint and will typically be flagged as public, while this pool is typically flagged as private. |
addressPoolBlueprints Schema
<addressPoolBlueprints>
<!-- see <addressPoolBlueprint> schema -->
</addressPoolBlueprints>Description: Each addressPoolBlueprints tag consists of zero or more addressPoolBlueprint tags.
addressRangeBlueprint Schema
<addressRangeBlueprint>
<defaultRangeMask></defaultRangeMask>
<defaultPoolMask></defaultPoolMask>
<defaultPublicFlag></defaultPublicFlag>
<ipv6Flag></ipv6Flag>
<name></name>
</addressRangeBlueprint>
Description:
Each addressRangeBlueprint tag partially specifies how to create an address range. An address range is a group of contiguous container level address pools of equal size, where a container level address pool is a pool that only one container on the pod can acquire addresses from. The partial specification of the range in this tag is supplemented with additional input from the user for the specific range address and range mask involved in the pod creation wizard page.
Children:
| Tag | Description |
|---|---|
defaultPublicFlag | Controls whether the range should be initially flagged as public or not when the pod creation wizard page is presented for creating the address range (the user can override this initial value in the wizard). |
defaultRangeMask | (Optional) Defines the initial value populated into the range mask field in the pod creation wizard for that particular address range. The value for defaultRangeMask should be less than the value set for defaultPoolMask. |
defaultPoolMask | Controls the initial value shown for the size of the pools within the range when the pod creation wizard page is presented for creating the range (the user can override this initial value in the wizard). It is specified as a dotted decimal mask value (for example, 255.255.255.64) or as a CIDR bit size (for example, 26). |
ipv6Flag | (Optional) Identifies whether the address range blueprint is IPv6. |
name | Specifies a way to uniquely identify this address range within the pod. |
addressRangeBlueprints Schema
<addressRangeBlueprints>
<!-- see <addressRangeBlueprint> schema -->
</addressRangeBlueprints>Description: Each addressRangeBlueprints tag consists of zero or more addressRangeBlueprint tags.
balancedParamBlueprint Schema
<balancedParamBlueprint>
<description></description>
<min></min>
<max></max>
<name></name>
<numValues></numValues>
<pattern></pattern>
<type></type>
</balancedParamBlueprint>Description:
Each balancedParamBlueprint tag partially specifies how to create a balanced parameter. A balanced parameter associates a name with a set of multiple values. The partial specification of the parameter in this tag is supplemented with additional input from the user for the set of values involved in the pod creation wizard page.
The parameter name can be referenced symbolically via substitution parameter in a template used to configure a device on behalf of a container on the pod. One particular value from the parameter's set of values will be plugged into the template before it is merged to the device. The value is selected by indexing into the set based on a modulo operation involving the ID of the container instance involved and the number of values in the set, using zero based indexing.
Note that balanced parameters can be declared at either the pod level, node level, or pair level. Those specified at the pod level are intended to reflect general qualities that apply to the overall pod. If you are reflecting qualities that apply to one particular node within the pod, BMC recommends that you specify them as balanced parameters at the node level instead, and if you are reflecting qualities that apply to one particular pair within the pod, BMC recommends that you specify them as balanced parameters at the pair level.
For instance, say a pod level balanced parameter named "My Balanced Parameter" was created with the set of values {"X", "Y"}. Consider also say you are going to create containers on this pod using a template that has the reference "${pod.balancedParams[My Balanced Parameter]}" in it. If you create ContainerA on this pod, with an ID of 0, then you would use an index of 0 to select the value, yielding "X" in the template, since "0 % 2 = 0". If you create ContainerB on this pod, with an ID of 1, you would use an index of 1 to select the value, yielding "Y", since "1 % 2 = 1". If you create ContainerC on this pod, with an ID of 2, you would use an index of 0 to select the value, yielding "X", since "2 % 2 = 0".
The selection of which value to use in the set therefore alternates from one container instance to the next, guaranteeing a balanced distribution of values. This is useful for instance if you want to balance the traffic within your pod across redundant interfaces between devices in the pod. To do that you might define a balanced parameter named "My Interface Name" with values {"GigabitEthernet0/1", "GigabitEthernet0/2"}, so that half the containers get configured to pass traffic through the first interface, while the other half gets configured to pass traffic through the second interface.
Children:
| Tag | Description |
|---|---|
description | (Optional) Is presented as a reminder to the user of the purpose of the balanced parameter when populating its value in the pod creation wizard, or when viewing its value later in the pod viewer. |
max | (Optional) Is only applicable if the type is Integer. A value of 15 would mean that the specified values must be less than or equal to 15. The enforcement of the max is done during pod creation. |
min | (Optional) Is only applicable if the type is Integer. A value of 5 would mean that the specified values must be greater than or equal to 5. The enforcement of the min is done during pod creation. |
name | Specifies a way to uniquely identify this balanced parameter among the pod level balanced parameters. |
numValues | Controls how many values the user will be required to enter when the pod creation wizard page is presented for creating this parameter. Typically the value will be 2. |
pattern | (Optional) Is only applicable when the type is String. This can be used to specify a java regular expression. The values need to conform to the regular expression. For example, a pattern of "abc \S+ xyz" would require that the value begin with "abc", followed by one or more non spaces, followed by "xyz". Refer to the standard javadoc for the java.util.regex.Pattern class for details on java regular expression syntax. The enforcement of the pattern is done during pod creation. |
type | (Optional) Specifies the type of the parameter. The valid values are String, Integer and Address. String means any the values can be any alpha-numeric string. Integer means the values need to be integer. Address means the values need to be a valid IP address. |
balancedParamBlueprints Schema
<balancedParamBlueprints>
<!-- see <balancedParamBlueprint> schema -->
</balancedParamBlueprints>Description: Each balancedParamBlueprints tag consists of zero or more balancedParamBlueprint tags.
bbnaData schema
<bbnaData>
<podBlueprint>
<!-- see podBlueprint schema -->
</podBlueprint>
<version>
<!-- see version schema -->
</version>
</bbnaData>Description:
The bbnaData tag is the root tag used to encapsulate an importable version stamped BMC Network Automation component, in this case a pod blueprint.
Children:
| Tag | Description |
|---|---|
podBlueprint | See podBlueprint schema. |
version | See version schema. |
dnsInfoBlueprint Schema
<dnsInfoBlueprint>
<defaultPrimaryDnsServer></defaultPrimaryDnsServer>
<defaultSecondaryDnsServer></defaultSecondaryDnsServer>
<defaultPrimaryDomainSuffixForNic></defaultPrimaryDomainSuffixForNic>
<defaultReverseDnsServer></defaultReverseDnsServer>
<defaultReverseDnsZone></defaultReverseDnsZone>
<defaultDnsDomainsForNic>
<dnsDomain></dnsDomain>
<dnsDomain></dnsDomain>
</defaultDnsDomainsForNic>
</dnsInfoBlueprint>Description:
The dnsInfoBlueprint tag partially specifies default DNS information for a pod. These default values are populated as a default while creating a pod. This is an optional tag.
.Children:
| Tag | Description |
|---|---|
defaultPrimaryDnsServer | Specifies the primary DNS server name. This is mandatory when other tag related to DNS is provided. |
defaultSecondaryDnsServer | Specifies the secondary DNS server name. |
defaultPrimaryDomainSuffixForNic | Specifies the primary domain suffix for NIC segments. This tag is required if you want to register the VM to the DNS server by using BMC Network Automation. |
| defaultReverseDnsServer | Specifies the default name of the Reverse DNS server. |
| defaultReverseDnsZone | Specifies the default name of the Reverse DNS zone. The Reverse DNS/Lookup zone holds the PTR records, which are used to resolve the fully-qualified domain names (FQDNs) from the IP address. |
defaultDnsDomainsForNic | (Optional) Specifies the domain search order. It has dnsDomain, a child tag. The domain order is followed as per the sequence specified in this tag. |
faultIdPoolBlueprint Schema
<faultIdPoolBlueprint>
<defaultEndNum></defaultEndNum>
<name></name>
<defaultStartNum></defaultStartNum>
</faultIdPoolBlueprint>Description:
The faultIdPoolBlueprint tag partially specifies how to create an integer pool to use for fault IDs for VLBs created on a podPair with an xsi:type of podIndividualFaultHostPairBlueprint. Each VLB will receive its own fault ID pool, and each LB pool created within the VLB will receive its own fault ID from it. The partial specification of the pool in this tag is supplemented with additional input from the user for specific numbers within the range to mark as excluded which cannot be acquired by containers.
Children:
| Tag | Description |
|---|---|
defaultEndNum | Specifies an initial value to present for the upper limit (inclusive) for the pool in the pod creation wizard page (the user can override this initial value). |
defaultStartNum | Specifies an initial value to present for the lower limit (inclusive) for the pool in the pod creation wizard page (the user can override this initial value). |
name | Specifies a way to identify the pool within the pair. |
integerPoolBlueprint Schema
<integerPoolBlueprint>
<defaultEndNum></defaultEndNum>
<name></name>
<defaultStartNum></defaultStartNum>
</integerPoolBlueprint>
Description:
Each integerPoolBlueprint tag partially specifies how to create an integer pool. An integer pool defines a range of numeric values that each container on the pod can acquire entries from, to use for any purpose where such a per-container unique value is needed. The partial specification of the pool in this tag is supplemented with additional input from the user for specific numbers within the range to mark as excluded which cannot be acquired by containers.
Children:
| Tag | Description |
|---|---|
defaultEndNum | Specifies an initial value to present for the upper limit (inclusive) for the pool in the pod creation wizard page (the user can override this initial value). |
defaultStartNum | Specifies an initial value to present for the lower limit (inclusive) for the pool in the pod creation wizard page (the user can override this initial value). |
name | Specifies a way to uniquely identify this VLAN pool within the pod. |
integerPoolBlueprints Schema
<integerPoolBlueprints>
<!-- see integerPoolBlueprint schema -->
</integerPoolBlueprints>Description: Each integerPoolBlueprints tag consists of zero or more integerPoolBlueprint tags.
nicSegmentBlueprint Schema
<nicSegmentBlueprint>
<addressPoolName></addressPoolName>
<customerFlag></customerFlag>
<name></name>
<managementFlag></managementFlag>
<networkName></networkName>
<tag></tag>
<vlanName></vlanName>
</nicSegmentBlueprint>Description:
The NIC segment specifies a network segment where virtual or physical servers can be attached.
Children:
| Tag | Description |
|---|---|
addressPoolName | Specifies the address pool which will be used to acquire server NIC addresses. This tag is optional, to allow for the possibility that the user is using DHCP for the acquired NIC addresses. |
customerFlag | Defines whether this NIC segment carries data (non-management) traffic or not. |
managementFlag | Defines whether this NIC segment carries management traffic or not. |
name | Specifies a way to uniquely identify this NIC segment within the pod. |
networkName | Is not used by BMC Network Automation, but corresponds to the name of the BMC Cloud Lifecycle Management network this NIC segment belongs to. |
tag | Is not used by BMC Network Automation, but corresponds to the default BMC Cloud Lifecycle Management tag used to provision server NICs to this segment. |
vlanName | Specifies the VLAN which will carry traffic for this NIC segment. This field is optional if the VLAN is being managed by an external entity, and not by the BMC Network Automation pod. For example, in case of a new Software Defined Networking (SDN) container, you can omit this field. |
nicSegmentBlueprints Schema
<nicSegmentBlueprints>
<!-- see nicSegmentBlueprint schema -->
</nicSegmentBlueprints>Description: Each nicSegmentBlueprints tag consists of zero or more nicSegmentBlueprint tags.
nodeBlueprint Schema (default xsi:type)
<nodeBlueprint>
<balancedParamBlueprints>
<!-- see balancedParamBlueprint schema -->
</balancedParamBlueprints>
<category></category>
<defaultMaxVrfs></defaultMaxVrfs>
<defaultAllowDeviceInUseByOtherNode></defaultAllowDeviceInUseByOtherNode>
<defaultAllowDeviceInUseByOtherPod></defaultAllowDeviceInUseByOtherPod>
<name></name>
<optionalFlag></optionalFlag>
<paramBlueprints>
<!-- see paramBlueprint schema -->
</paramBlueprints>
<role></role>
</nodeBlueprint>Description:
Each nodeBlueprint tag partially specifies how to create a pod node. A pod node represents one particular BMC Network Automation network device, decorated with some additional information specific to management of the device by the pod instance. The partial specification of the node in this tag is supplemented with additional input from the user for the selection of the BMC Network Automation network device and parameter values involved, in the pod creation wizard page.
The nodeBlueprint tag, with a default xsi:type value, partially specifies how to create a basic (vanilla) type of pod node. A basic node represents an infrastructure device within the pod, which does not require additional administration after being initially configured for a given container instance. This includes all pod devices except firewall hosts, load balancer hosts, and access switches, since each of those require additional administration.
Children:
| Tag | Description |
|---|---|
balancedParamBlueprints | Consists of zero or more balancedParamBlueprint tags. See balancedParamBlueprint schema. |
category | Is used to filter the list of available devices to select from when creating this node to just those devices with a matching category value. The category value must be one of the allowed values for BMC Network Automation device categories, as defined in CategoryMap.xml (for example, "1" for a router, "2" for a switch, "4" for a firewall, "7" for a load balancer, and so on). Devices with a category value of "Other" are always included in the selection list. |
defaultMaxVrfs | (Optional) Specifies an initial upper limit to the number of VRFs which can be hosted on this device (the user can override this initial value in the wizard page). The container blueprints used to configure containers on pods specify how many VRFs they add to each device in the pod. The pod keeps track of how many VRFs have been added to each of its devices, and will not allow those limits to be exceeded by attempts to add new containers. Note that the correct upper limit to use for any given device is likely to be a function of the particular model involved and how much memory it has, so defining a default upper limit which is hardware independent may not be very useful. |
defaultAllowDeviceInUseByOtherPod | Controls whether the list of devices to select from should initially include devices already in use by other pods or not. You can override this initial value in the wizard page. If the flag is true, then devices already in use by other pods will be included in the device selection list for this node. |
| defaultAllowDeviceInUseByOtherNode | Controls whether the list of devices to select from should initially include devices already in use by other nodes or not. You can override this initial value in the wizard page. If the flag is true, then devices already in use by other nodes within this pod are included in the device selection list for this node. |
name | Specifies a way to uniquely identify this node within the pod. |
optionalFlag | Controls whether the user is allowed to skip this node blueprint in the pod creation wizard. For instance, the reference large pod blueprint from Cisco calls for 3 pairs of fault tolerant firewall host nodes, even though the container blueprint for creating gold containers only calls for one pair of these nodes. The choice of which pair to use for a given container instance is automatically made in such a way as to balance the usage across all 3 pairs, thus providing extra scalability for the pod. The blueprints for the nodes in the second and third pairs are flagged as optional however, which allows users the flexibility to skip them when they create their pods, if they do not require this scalability. |
paramBlueprints | Consists of zero or more paramBlueprint tags. See paramBlueprint schema. |
role | Identifies the role which this node plays within the pod. For example a value of "Edge" could be specified to indicate that this is the node is at the edge of the pod. If there were two such edge nodes within the pod, paired for redundancy, then each would need a unique role value (for example, "Edge 1" and "Edge 2"). The role value specified for a pod node is matched against the role values specified by container nodes within a container blueprint when deciding where to host each container node within a pod. If there are multiple pod nodes with the same role value, then the choice of which one to host the container node on will be made in such a way as to automatically balance the usage of the underlying pod nodes from one container instance to the next, for scalability. |
nodeBlueprint Schema (xsi:type="podFirewallHostBlueprint")
<nodeBlueprint xsi:type="podFirewallHostBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<balancedParamBlueprints>
<!-- see balancedParamBlueprint schema -->
</balancedParamBlueprints>
<category></category>
<defaultMaxRulesPerVfw></defaultMaxRulesPerVfw>
<defaultMaxVfws></defaultMaxVfws>
<defaultMaxVrfs></defaultMaxVrfs>
<defaultAllowDeviceInUseByOtherNode></defaultAllowDeviceInUseByOtherNode>
<defaultAllowDeviceInUseByOtherPod></defaultAllowDeviceInUseByOtherPod>
<name></name>
<optionalFlag></optionalFlag>
<paramBlueprints>
<!-- see paramBlueprint schema -->
</paramBlueprints>
<role></role>
</nodeBlueprint>Description:
Each nodeBlueprint tag partially specifies how to create a pod node. A pod node represents one particular BMC Network Automation network device, decorated with some additional information specific to management of the device by the pod instance. The partial specification of the node in this tag is supplemented with additional input from the user for the selection of the BMC Network Automation nework device and parameter values involved, in the pod creation wizard page.
The nodeBlueprint tag, with an xsi:type value of podFirewallHostBlueprint, partially specifies how to create a firewall host type of pod node. A firewall host node represents a device within the pod on which virtual guest firewalls (VFWs) can be created (e.g. a Cisco FWSM or ASA), one per container instance. A single ACL (for example, list of inbound permit/deny rules) for the VFW can later be administered from the BMC Cloud Lifecycle Management (either ad hoc via a GUI or automatically during server provisioning).
Children:
| Tag | Description |
|---|---|
balancedParamBlueprints | Consists of zero or more balancedParamBlueprint tags. See balancedParamBlueprint schema. |
category | Is used to filter the list of available devices to select from when creating this node to just those devices with a matching category value. The category value must be one of the allowed values for BMC Network Automation device categories, as defined in CategoryMap.xml (for example, "1" for a router, "2" for a switch, "4" for a firewall, "7" for a load balancer, and so on.) Devices with a category value of "Other" are always included in the selection list. If the xsi:type value for the nodeBlueprint tag is podHostFirewallBlueprint, the category value should be 4. |
| defaultAllowDeviceInUseByOtherPod | Controls whether the list of devices to select from should initially include devices already in use by other pods or not. You can can override this initial value in the wizard page. If the flag is true, then devices already in use by other pods are included in the device selection list for this node. |
| defaultAllowDeviceInUseByOtherNode | Controls whether the list of devices to select from should initially include devices already in use by other nodes or not. You can override this initial value in the wizard page. If the flag is true, then devices already in use by other nodes within this pod are included in the device selection list for this node. |
defaultMaxRulesPerVfw | (Optional) Specifies an initial upper limit to the number of ACL rules which can be specified per ACL in a given VFW (the user can override this initial value in the wizard page). The container keeps track of how many rules have been added to the ACL for a given VFW, and will not allow that limit to be exceeded by attempts to add new rules. Note that the correct upper limit to use for any given guest is likely to be a function of the particular model involved and how much memory it has, so defining a default upper limit which is hardware independent may not be very useful. |
defaultMaxVfws | (Optional) Specifies an initial upper limit to the number of VFWs which can be created on this firewall host (the user can override this initial value in the wizard page). The pod keeps track of how many VFWs have been added to the firewall host, and will not allow that limit to be exceeded by attempts to add new VFWs. Note that the correct upper limit to use for any given host is likely to be a function of the particular model involved and how much memory it has, so defining a default upper limit which is hardware independent may not be very useful. |
defaultMaxVrfs | (Optional) Specifies an initial upper limit to the number of VRFs which can be hosted on this device (the user can override this initial value in the wizard page). The container blueprints used to configure containers on pods specify how many VRFs they add to each device in the pod. The pod keeps track of how many VRFs have been added to each of its devices, and will not allow those limits to be exceeded by attempts to add new containers. Note that the correct upper limit to use for any given device is likely to be a function of the particular model involved and how much memory it has, so defining a default upper limit which is hardware independent may not be very useful. |
name | Specifies a way to uniquely identify this node within the pod. |
optionalFlag | (Optional) Controls whether the user is allowed to skip this node blueprint in the pod creation wizard. For instance, the reference large pod blueprint from Cisco calls for 3 pairs of fault tolerant firewall host nodes, even though the container blueprint for creating gold containers only calls for one pair of these nodes. The choice of which pair to use for a given container instance is automatically made in such a way as to balance the usage across all 3 pairs, thus providing extra scalability for the pod. The blueprints for the nodes in the 2nd and 3rd pairs are flagged as optional however, which allows users the flexibility to skip them when they create their pods, if they do not require this scalability. |
paramBlueprints | Consists of zero or more paramBlueprint tags. See paramBlueprint schema . |
role | Identifies the role which this node plays within the pod. For a value of "Edge" could be specified to indicate that this is the node is at the edge of the pod. If there were two such edge nodes within the pod, paired for redundancy, then each would need a unique role value (for example, "Edge 1" and "Edge 2"). The role value specified for a pod node is matched against the role values specified by container nodes within a container blueprint when deciding where to host each container node within a pod. If there are multiple pod nodes with the same role value, then the choice of which one to host the container node on will be made in such a way as to automatically balance the usage of the underlying pod nodes from one container instance to the next, for scalability. |
nodeBlueprint Schema (xsi:type="podHostBlueprint")
<nodeBlueprint xsi:type="podHostBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<balancedParamBlueprints>
<!-- see balancedParamBlueprint schema -->
</balancedParamBlueprints>
<category></category>
<defaultAllowDeviceInUseByOtherNode></defaultAllowDeviceInUseByOtherNode>
<defaultAllowDeviceInUseByOtherPod></defaultAllowDeviceInUseByOtherPod>
<name></name>
<optionalFlag></optionalFlag>
<paramBlueprints>
<!-- see paramBlueprint schema -->
</paramBlueprints>
<role></role>
</nodeBlueprint>Description:
Each nodeBlueprint tag partially specifies how to create a pod node. A pod node represents one particular BMC Network Automation network device, decorated with some additional information specific to management of the device by the pod instance. The partial specification of the node in this tag is supplemented with additional input from the user for the selection of the BMC Network Automation network device and parameter values involved, in the pod creation wizard page.
The nodeBlueprint tag, with an xsi:type value of podHostBlueprint, partially specifies how to create a host type of pod node. A virtual guest is created for the pod on this host node. For example, a Cisco CSR 100V), one per container instance.
Children:
| Tag | Description |
|---|---|
balancedParamBlueprints | Consists of zero or more balancedParamBlueprint tags. See balancedParamBlueprint schema. |
category | The category value must be one of the allowed values for BMC Network Automation device categories, as defined in CategoryMap.xml (for example, "1" for a router, "2" for a switch, "4" for a firewall, "7" for a load balancer, and so on). The value specified will be used to filter the list of available devices to select from when creating this node to just those devices with a matching category value. Devices with a category value of "Other" are always included in the selection list. |
defaultAllowDeviceInUseByOtherPod | Controls whether the list of devices to select from initially include devices already in use by other pods or not. You can override this initial value in the wizard page. If the flag is true, then devices already in use by other pods are included in the device selection list for this node. |
| defaultAllowDeviceInUseByOtherNode | Controls whether the list of devices to select from should initially include devices already in use by other nodes or not. You can override this initial value in the wizard page. If the flag is true, then devices already in use by other nodes within this pod are included in the device selection list for this node. |
name | Specifies a way to uniquely identify this node within the pod. |
optionalFlag | Controls whether the user is allowed to skip this node blueprint in the pod creation wizard. For instance, the reference large pod blueprint from Cisco calls for 3 pairs of fault tolerant firewall host nodes, even though the container blueprint for creating gold containers only calls for one pair of these nodes. The choice of which pair to use for a given container instance is automatically made in such a way as to balance the usage across all 3 pairs, thus providing extra scalability for the pod. The blueprints for the nodes in the 2nd and 3rd pairs are flagged as optional however, which allows users the flexibility to skip them when they create their pods, if they do not require this scalability. |
paramBlueprints | Consists of zero or more paramBlueprint tags. See paramBlueprint schema. |
role | Identifies the role which this node plays within the pod. For a value of "Edge" could be specified to indicate that this is the node is at the edge of the pod. If there were two such edge nodes within the pod, paired for redundancy, then each would need a unique role value (for example, "Edge 1" and "Edge 2"). The role value specified for a pod node is matched against the role values specified by container nodes within a container blueprint when deciding where to host each container node within a pod. If there are multiple pod nodes with the same role value, then the choice of which one to host the container node on will be made in such a way as to automatically balance the usage of the underlying pod nodes from one container instance to the next, for scalability. |
nodeBlueprint Schema (xsi:type="podHypervisorSwitchBlueprint")
<nodeBlueprint xsi:type="podHypervisorSwitchBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<balancedParamBlueprints>
<!-- see balancedParamBlueprint schema -->
</balancedParamBlueprints>
<category></category>
<defaultMaxPorts></defaultMaxPorts>
<defaultMaxPortTypes></defaultMaxPortTypes>
<defaultMaxVrfs></defaultMaxVrfs>
<defaultAllowDeviceInUseByOtherNode></defaultAllowDeviceInUseByOtherNode>
<defaultAllowDeviceInUseByOtherPod></defaultAllowDeviceInUseByOtherPod>
<name></name>
<optionalFlag></optionalFlag>
<paramBlueprints>
<!-- see paramBlueprint schema -->
</paramBlueprints>
<portTypeBlueprints>
<!-- see portTypeBlueprint schema -->
</portTypeBlueprints>
<role></role>
</nodeBlueprint>Description:
Each nodeBlueprint tag partially specifies how to create a pod node. A pod node represents one particular BMC Network Automation network device, decorated with some additional information specific to management of the device by the pod instance. The partial specification of the node in this tag is supplemented with additional input from the user for the selection of the BMC Network Automation network device and parameter values involved, in the pod creation wizard page.
The nodeBlueprint tag, with an xsi:type value of podHypervisorSwitchBlueprint, partially specifies how to create a hypervisor switch type of pod node. A hypervisor switch node represents a device within the pod which controls switching for a given hypervisor server or cluster that virtual servers are being provisioned to (for example, a Cisco Nexus 1000v or a VMWare VSwitch), one per container instance.
Children:
| Tag | Description |
|---|---|
balancedParamBlueprints | Consists of zero or more balancedParamBlueprint tags. See balancedParamBlueprint schema. |
category | The category value must be one of the allowed values for BMC Network Automation device categories, as defined in CategoryMap.xml (for example, "1" for a router, "2" for a switch, "4" for a firewall, "7" for a load balancer, ...). The value specified is used to filter the list of available devices to select from when creating this node to just those devices with a matching category value. Devices with a category value of "Other" are always included in the selection list. |
| defaultAllowDeviceInUseByOtherNode | Controls whether the list of devices to select from should initially include devices already in use by other nodes or not. You can override this initial value in the wizard page. If the flag is true, then devices already in use by other nodes within this pod are included in the device selection list for this node. |
| defaultAllowDeviceInUseByOtherPod | Controls whether the list of devices to select from should initially include devices already in use by other pods or not. You can override this initial value in the wizard page. If the flag is true, then devices already in use by other pods are included in the device selection list for this node. |
defaultMaxPorts | (Optional) Specifies an initial upper limit to the number of virtual ports which can be created in the hypervisor switch (the user can override this initial value in the wizard page). A virtual port is created on the switch for each NIC added to it during virtual server provisioning. The pod keeps track of how many virtual ports have been created on the switch, and will not allow that limit to be exceeded by attempts to create new ports. Note that the correct upper limit to use for any given switch is likely to be a function of the particular model involved, so defining a default upper limit which is hardware independent may not be very useful. |
defaultMaxPortTypes | (Optional) Specifies an initial upper limit to the number of virtual port types which can be created in the hypervisor switch (the user can override this initial value in the wizard page). A virtual port type is our vender neutral term for what VMWare calls a port group and what Cisco calls a port profile. The virtual port type is used by the switch to create a given virtual port for a given NIC being attached to the switch. There will be one virtual port type for each NIC segment attached to the switch, for each container instance on the pod. Note that the correct upper limit to use for any given switch is likely to be a function of the particular model involved, so defining a default upper limit which is hardware independent may not be very useful. |
defaultMaxVrfs | (Optional) Specifies an initial upper limit to the number of VRFs which can be hosted on this device (the user can override this initial value in the wizard page). The container blueprints used to configure containers on pods specify how many VRFs they add to each device in the pod. The pod keeps track of how many VRFs have been added to each of its devices, and will not allow those limits to be exceeded by attempts to add new containers. Note that the correct upper limit to use for any given device is likely to be a function of the particular model involved and how much memory it has, so defining a default upper limit which is hardware independent may not be very useful. |
name | Specifies a way to uniquely identify this node within the pod. |
optionalFlag | Controls whether the user is allowed to skip this node blueprint in the pod creation wizard. For instance, the reference large pod blueprint from Cisco calls for three pairs of fault tolerant firewall host nodes, even though the container blueprint for creating gold containers only calls for one pair of these nodes. The choice of which pair to use for a given container instance is automatically made in such a way as to balance the usage across all 3 pairs, thus providing extra scalability for the pod. The blueprints for the nodes in the second and third pairs are flagged as optional however, which allows users the flexibility to skip them when they create their pods, if they do not require this scalability. |
paramBlueprints | Consists of zero or more paramBlueprint tags. See paramBlueprint schema. |
portTypeBlueprints | Consists of one or more portTypeBlueprint tags. See portTypeBlueprint schema. |
role | Identifies the role which this node plays within the pod. For example a value of "Edge" could be specified to indicate that this is the node is at the edge of the pod. If there were two such edge nodes within the pod, paired for redundancy, then each would need a unique role value (for example, "Edge 1" and "Edge 2"). The role value specified for a pod node is matched against the role values specified by container nodes within a container blueprint when deciding where to host each container node within a pod. If there are multiple pod nodes with the same role value, then the choice of which one to host the container node on will be made in such a way as to automatically balance the usage of the underlying pod nodes from one container instance to the next, for scalability. |
nodeBlueprint Schema (xsi:type="podLoadBalancerHostBlueprint")
<nodeBlueprint xsi:type="podLoadBalancerHostBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<balancedParamBlueprints>
<!-- see balancedParamBlueprint schema -->
</balancedParamBlueprints>
<category></category>
<defaultMaxEntriesPerPool></defaultMaxEntriesPerPool>
<defaultMaxPoolsPerVlb></defaultMaxPoolsPerVlb>
<defaultMaxVlbs></defaultMaxVlbs>
<defaultMaxVrfs></defaultMaxVrfs>
<defaultAllowDeviceInUseByOtherNode></defaultAllowDeviceInUseByOtherNode>
<defaultAllowDeviceInUseByOtherPod></defaultAllowDeviceInUseByOtherPod>
<name></name>
<optionalFlag></optionalFlag>
<paramBlueprints>
<!-- see paramBlueprint schema -->
</paramBlueprints>
<role></role>
</nodeBlueprint>Description:
Each nodeBlueprint tag partially specifies how to create a pod node. A pod node represents one particular BMC Network Automation network device, decorated with some additional information specific to management of the device by the pod instance. The partial specification of the node in this tag is supplemented with additional input from the user for the selection of the BMC Network Automation nework device and parameter values involved, in the pod creation wizard page.
The nodeBlueprint tag, with an xsi:type value of podLoadBalancerHostBlueprint, partially specifies how to create a load balancer host type of pod node. A load balancer host node represents a device within the pod on which virtual guest load balancers (VLBs) can be created (for example, a Cisco ACE), one per container instance. Pools can later be added to the VLB, and server NIC entries can be added to those pools, administered from the BMC Cloud Lifecycle Management (either ad hoc via a GUI or automatically during server provisioning).
Children:
| Tag | Description |
|---|---|
balancedParamBlueprints | Consists of zero or more balancedParamBlueprint tags. See balancedParamBlueprint schema. |
category | The category value must be one of the allowed values for BMC Network Automation device categories, as defined in CategoryMap.xml (for example, "1" for a router, "2" for a switch, "4" for a firewall, "7" for a load balancer, ...). The value specified is used to filter the list of available devices to select from when creating this node to just those devices with a matching category value. Devices with a category value of "Other" are always included in the selection list. |
| defaultAllowDeviceInUseByOtherPod | Controls whether the list of devices to select from should initially include devices already in use by other pods or not. You can override this initial value in the wizard page. If the flag is true, then devices already in use by other pods are included in the device selection list for this node. |
| defaultAllowDeviceInUseByOtherNode | Controls whether the list of devices to select from should initially include devices already in use by other nodes or not. You can override this initial value in the wizard page. If the flag is true, then devices already in use by other nodes within this pod are included in the device selection list for this node. |
defaultMaxEntriesPerPool | (Optional) Specifies an initial upper limit to the number of server NIC entries which can be added to a given pool within the VLB (the user can override this initial value in the wizard page). The container keeps track of how many entries have been added to each pool in a given VLB, and will not allow that limit to be exceeded by attempts to add new entries. Note that the correct upper limit to use for any given guest is likely to be a function of the particular model involved and how much memory it has, so defining a default upper limit which is hardware independent may not be very useful. |
defaultMaxVlbs | (Optional) Specifies an initial upper limit to the number of VLBs which can be created on this firewall host (the user can override this initial value in the wizard page). The pod keeps track of how many VLBs have been added to the firewall host, and will not allow that limit to be exceeded by attempts to add new VLBs. Note that the correct upper limit to use for any given host is likely to be a function of the particular model involved and how much memory it has, so defining a default upper limit which is hardware independent may not be very useful. |
defaultMaxVrfs | (Optional) Specifies an initial upper limit to the number of VRFs which can be hosted on this device (the user can override this initial value in the wizard page). The container blueprints used to configure containers on pods specify how many VRFs they add to each device in the pod. The pod keeps track of how many VRFs have been added to each of its devices, and will not allow those limits to be exceeded by attempts to add new containers. Note that the correct upper limit to use for any given device is likely to be a function of the particular model involved and how much memory it has, so defining a default upper limit which is hardware independent may not be very useful. |
name | Specifies a way to uniquely identify this node within the pod. |
optionalFlag | Controls whether the user is allowed to skip this node blueprint in the pod creation wizard. For instance, the reference large pod blueprint from Cisco calls for 3 pairs of fault tolerant firewall host nodes, even though the container blueprint for creating gold containers only calls for one pair of these nodes. The choice of which pair to use for a given container instance is automatically made in such a way as to balance the usage across all 3 pairs, thus providing extra scalability for the pod. The blueprints for the nodes in the second and third pairs are flagged as optional however, which allows users the flexibility to skip them when they create their pods, if they do not require this scalability. |
paramBlueprints | Consists of zero or more paramBlueprint tags. See paramBlueprint schema. |
role | Identifies the role which this node plays within the pod. For example a vallue of "Edge" could be specified to indicate that this is the node is at the edge of the pod. If there were two such edge nodes within the pod, paired for redundancy, then each would need a unique role value (for example, "Edge 1" and "Edge 2"). The role value specified for a pod node is matched against the role values specified by container nodes within a container blueprint when deciding where to host each container node within a pod. If there are multiple pod nodes with the same role value, then the choice of which one to host the container node on will be made in such a way as to automatically balance the usage of the underlying pod nodes from one container instance to the next, for scalability. |
nodeBlueprint Schema (xsi:type="podPhysicalSwitchBlueprint")
<nodeBlueprint xsi:type="podPhysicalSwitchBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<balancedParamBlueprints>
<!-- see balancedParamBlueprint schema -->
</balancedParamBlueprints>
<category></category>
<defaultMaxVrfs></defaultMaxVrfs>
<defaultAllowDeviceInUseByOtherNode></defaultAllowDeviceInUseByOtherNode>
<defaultAllowDeviceInUseByOtherPod></defaultAllowDeviceInUseByOtherPod>
<name></name>
<optionalFlag></optionalFlag>
<paramBlueprints>
<!-- see paramBlueprint schema -->
</paramBlueprints>
<role></role>
</nodeBlueprint>Description:
Each nodeBlueprint tag partially specifies how to create a pod node. A pod node represents one particular BMC Network Automation network device, decorated with some additional information specific to management of the device by the pod instance. The partial specification of the node in this tag is supplemented with additional input from the user for the selection of the BMC Network Automation nework device and parameter values involved, in the pod creation wizard page.
The nodeBlueprint tag, with an xsi:type value of podPhysicalSwitchBlueprint, partially specifies how to create a physical access switch type of pod node. A physical switch node represents a device within the pod where physical servers can be connected.
Children:
| Tag | Description |
|---|---|
balancedParamBlueprints | Consists of zero or more balancedParamBlueprint tags. See balancedParamBlueprint schema. |
category | The category value must be one of the allowed values for BMC Network Automation device categories, as defined in CategoryMap.xml (for example, "1" for a router, "2" for a switch, "4" for a firewall, "7" for a load balancer, ...). The value specified will be used to filter the list of available devices to select from when creating this node to just those devices with a matching category value. Devices with a category value of "Other" are always included in the selection list. |
| defaultAllowDeviceInUseByOtherPod | Controls whether the list of devices to select from should initially include devices already in use by other pods or not. You can override this initial value in the wizard page. If the flag is true, devices already in use by other pods are included in the device selection list for this node. If the xsi:type value for the nodeBlueprint tag is podPhysicalSwitchBlueprint, the defaultAllowDeviceInUseByOtherPod must be false, since sharing of access switches across pods is not allowed. |
| defaultAllowDeviceInUseByOtherNode | Controls whether the list of devices to select from should initially include devices already in use by other nodes or not. You can override this initial value in the wizard page. If the flag is true, then devices already in use by other nodes within this pod are included in the device selection list for this node. |
defaultMaxVrfs | (Optional) Specifies an initial upper limit to the number of VRFs which can be hosted on this device (the user can override this initial value in the wizard page). The container blueprints used to configure containers on pods specify how many VRFs they add to each device in the pod. The pod keeps track of how many VRFs have been added to each of its devices, and will not allow those limits to be exceeded by attempts to add new containers. Note that the correct upper limit to use for any given device is likely to be a function of the particular model involved and how much memory it has, so defining a default upper limit which is hardware independent may not be very useful. |
name | Specifies a way to uniquely identify this node within the pod. |
optionalFlag | Controls whether the user is allowed to skip this node blueprint in the pod creation wizard. For instance, the reference large pod blueprint from Cisco calls for 3 pairs of fault tolerant firewall host nodes, even though the container blueprint for creating gold containers only calls for one pair of these nodes. The choice of which pair to use for a given container instance is automatically made in such a way as to balance the usage across all 3 pairs, thus providing extra scalability for the pod. The blueprints for the nodes in the second and third pairs are flagged as optional however, which allows users the flexibility to skip them when they create their pods, if they do not require this scalability. |
paramBlueprints | Consists of zero or more paramBlueprint tags. See paramBlueprint schema. |
role | Identifies the role which this node plays within the pod. In the example below I have specified a value of "Edge" to indicate that this is the node is at the edge of the pod. If there were two such edge nodes within the pod, paired for redundancy, then each would need a unique role value (for example, "Edge 1" and "Edge 2"). The role value specified for a pod node is matched against the role values specified by container nodes within a container blueprint when deciding where to host each container node within a pod. If there are multiple pod nodes with the same role value, then the choice of which one to host the container node on will be made in such a way as to automatically balance the usage of the underlying pod nodes from one container instance to the next, for scalability. |
nodeBlueprints Schema
<nodeBlueprints>
<!-- see <nodeBlueprint schema -->
</nodeBlueprint>Description: Each nodeBlueprints tag consists of zero or more nodeBlueprint tags.
pairBlueprint Schema (default xsi:type)
<pairBlueprint>
<balancedParamBlueprints>
<!-- see balancedParamBlueprint schema -->
</balancedParamBlueprints>
<nodeBlueprints>
<nodeBlueprint></nodeBlueprint>
<nodeBlueprint></nodeBlueprint>
</nodeBlueprints>
<name></name>
<paramBlueprints>
<!-- see paramBlueprint schema -->
</paramBlueprints>
</pairBlueprint>Description:
Each pairBlueprint tag partially specifies how to create a pod pair. A pod pair associates two redundant nodes within the pod. The partial specification of the pair in this tag is supplemented with additional input from the user for the selection of the parameter values, in the pod creation wizard page.
The pairBlueprint tag, with a default xsi:type value, partially specifies how to create a basic (vanilla) type of pod pair. A basic pair specifies two nodes within the pod which provide redundancy, but which require no special logic at the pair level to achieve this which BMC Network Automation needs to model.
Children:
| Tag | Description |
|---|---|
balancedParamBlueprints | Consists of zero or more balancedParamBlueprint tags. See balancedParamBlueprint schema. |
name | Specifies a way to uniquely identify this pair within the pod. |
nodeBlueprints | Consists of two nodeBlueprint tags. Each nodeBlueprint tag specifies the name of a node blueprint already defined within the pod. Both node blueprints referenced must have the same xsi:type and category values. |
paramBlueprints | Consists of zero or more paramBlueprint tags. See paramBlueprint schema. |
pairBlueprint Schema (xsi:type="podCommunityFaultHostPairBlueprint")
<pairBlueprint xsi:type="podCommunityFaultHostPairBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<balancedParamBlueprints>
<!-- see balancedParamBlueprint schema -->
</balancedParamBlueprints>
<community1ManagementVlanName></community1ManagementVlanName>
<community2ManagementVlanName></community2ManagementVlanName>
<nodeBlueprints>
<nodeBlueprint></nodeBlueprint>
<nodeBlueprint></nodeBlueprint>
</nodeBlueprints>
<name></name>
<paramBlueprints>
<!-- see paramBlueprint schema -->
</paramBlueprints>
</pairBlueprint>Description:
Each pairBlueprint tag partially specifies how to create a pod pair. A pod pair associates two redundant nodes within the pod. The partial specification of the pair in this tag is supplemented with additional input from the user for the selection of the parameter values, in the pod creation wizard page.
The pairBlueprint tag, with an xsi:type value of podCommunityFaultHostPairBlueprint, partially specifies how to create a community fault host type of pod pair. A community fault host pair represents two nodes within the pod which provide redundancy using community style active-active fault tolerance.
Community style fault tolerance is a vendor independent term for the style of active-active fault tolerance used by the Cisco FWSM/ASA device type, where a VFW created on the FWSM/ASA host belongs to one of two fault groups (failover groups) already present in the host (group ID 1 or group ID 2). A given fault group is active on one host and standby on the other host. If a fault occurs in any VFW in a given group, all VFWs within its group transition to standby on that host and active on the other host. So the entire community of VFWs in the group respond together when a fault occurs in a given VFW.
Containers create a single virtual guest device on the host which has the currently active admin context, and that host automatically propagates the creation command to the other host. Specification of which host the guest should be active on alternates from one container instance to the next. Initialization of the guest configuration after it has been created occurs on the host where it is active, and that host automatically propagates the initialization commands to the guest device on the other host. After initialization is complete, the guest is assumed to have been assigned its own virtual IP address, allowing it to be administered afterwards (for example, to modify a firewall ACL) by directly connecting to it using that address, rather than connecting to its host and switching contexts.
Children:
balancedParamBlueprints | Consists of zero or more balancedParamBlueprint tags. See balancedParamBlueprint schema. |
community1ManagementVlanName | Specifies the default management VLAN name for community 1 fault group. This is an optional attribute. |
community2ManagementVlanName | Specifies the default management VLAN name for community 2 fault group. This is an optional attribute. |
name | Specifies a way to uniquely identify this pair within the pod. |
nodeBlueprints | Consists of two nodeBlueprint tags. Each nodeBlueprint tag specifies the name of a node blueprint already defined within the pod. Both node blueprints referenced must have the same xsi:type and category values. |
paramBlueprints | Consists of zero or more paramBlueprint tags. See paramBlueprint schema. |
pairBlueprint Schema (xsi:type="podIndividualFaultHostPairBlueprint")
<pairBlueprint xsi:type="podIndividualFaultHostPairBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<balancedParamBlueprints>
<!-- see balancedParamBlueprint schema -->
</balancedParamBlueprints>
<defaultActiveGuestPriority></defaultActiveGuestPriority>
<defaultStandbyGuestPriority></defaultStandbyGuestPriority>
<faultIdPoolBlueprint>
<defaultEndNum></defaultEndNum>
<name></name>
<defaultStartNum></defaultStartNum>
</faultIdPoolBlueprint>
<name></name>
<nodeBlueprints>
<nodeBlueprint></nodeBlueprint>
<nodeBlueprint></nodeBlueprint>
</nodeBlueprints>
<paramBlueprints>
<!-- see paramBlueprint schema -->
</paramBlueprints>
</pairBlueprint>Description:
Each pairBlueprint tag partially specifies how to create a pod pair. A pod pair associates two redundant nodes within the pod. The partial specification of the pair in this tag is supplemented with additional input from the user for the selection of the parameter values, in the pod creation wizard page.
The pairBlueprint tag, with an xsi:type value of podIndividualFaultHostPairBlueprint, partially specifies how to create an individual fault host type of pod pair. An individual fault host pair represents two nodes within the pod which provide redundancy using individual style active-active fault tolerance.
Individual style fault tolerance is a vendor independent term for the style of active-active fault tolerance used by the Cisco ACE device type, where a VLB created on the ACE host belongs to a dedicated fault group with its own unique id, which is created for it. The fault group is active on one host and standby on the other host. If a fault occurs in a given VLB, only that VLB's group transitions to standby on that host and active on the other host and none of the other groups are affected. So only that individual VLB's group responds when a fault occurs in a given VLB.
Containers will create a single virtual guest device on the host which has the currently active admin context, and that host will automatically propagate the creation command to the other host. Specification of which host the guest should be active on will alternate from one container instance to the next. Initialization of the guest configuration after it has been created will occur on the host where it is active, and that host will automatically propagate the initialization commands to the guest device on the other host. After initialization is complete, the guest will be assumed to have been assigned its own virtual IP address, allowing it to be administered afterwards (for example, to modify an LB pool) by directly connecting to it using that address, rather than connecting to its host and switching contexts.
Children:
| Tag | Description |
|---|---|
balancedParamBlueprints | Consists of zero or more balancedParamBlueprint tags. See balancedParamBlueprint schema. |
defaultActiveGuestPriority | Specifies the priority value that will be assigned to the active VLB in the fault tolerant pair. It should be greater than the defaultStandbyGuestPriority value. |
defaultStandbyGuestPriority | Specifies the priority value that will be assigned to the standby VLB in the fault tolerant pair. It should be less than the defaultActiveGuestPriority value. |
faultIdPoolBlueprint | |
name | Specifies a way to uniquely identify this pair within the pod. |
nodeBlueprints | Consists of two nodeBlueprint tags. Each nodeBlueprint tag specifies the name of a node blueprint already defined within the pod. Both node blueprints referenced must have the same xsi:type and category values. |
paramBlueprints | Consists of zero or more paramBlueprint tags. See paramBlueprint schema. |
pairBlueprints Schema
<pairBlueprints>
<!-- see <pairBlueprint schema -->
</pairBlueprints>Description: Each pairBlueprints tag consists of zero or more pairBlueprint tags.
paramBlueprint Schema
<paramBlueprint>
<description></description>
<min></min>
<max></max>
<name></name>
<pattern></pattern>
<sensitiveFlag></sensitiveFlag>
<type></type>
</paramBlueprint>Description:
Each paramBlueprint tag partially specifies how to create a simple parameter consisting of a name value pair. The partial specification of the parameter in this tag is supplemented with additional input from the user for the value involved in the pod creation wizard page.
The parameter name can be referenced symbolically via substitution parameter in a template used to configure a device on behalf of a container on the pod. The parameter value will be plugged into the template before it is merged to the device.
Note that parameters can be declared at either the pod level, node level, or pair level. Those specified at the pod level are intended to reflect general qualities that apply to the overall pod. If you are reflecting qualities that apply to one particular node within the pod, BMC recommends that you specify them as parameters at the node level instead. If you are reflecting qualities that apply to one particular pair within the pod, BMC recommends that you specify them as parameters at the pair level instead.
For instance, consider a pod level parameter named "My Simple Parameter" was created with the value "X". Consider also say you are going to create containers on this pod using a template that has the reference "${pod.params[My Simple Parameter]}" in it. If you create a container on this pod, then the template used to configure its device would replace that reference with "X" before merging it to the device.
Children:
| Tag | Description |
|---|---|
description | (Optional) Reminds the user of the purpose of the parameter when populating its value in the pod creation wizard, or when viewing its value later in the pod viewer. |
max | (Optional) Is only applicable if the type is Integer. A value of 15 would mean that the specified value must be less than or equal to 15. The enforcement of the max is done during pod creation. |
min | (Optional) Is only applicable if the type is Integer. A value of 5 would mean that the specified value must be greater than or equal to 5. The enforcement of the min is done during pod creation. |
pattern | (Optional) Is only applicable when the type is String. This can be used to specify a java regular expression. The values need to conform to the regular expression. For example, a pattern of "abc \S+ xyz" would require that the value begin with "abc", followed by one or more non spaces, followed by "xyz". Refer to the standard javadoc for the java.util.regex.Pattern class for details on java regular expression syntax. The enforcement of the pattern is done during pod creation. |
sensitiveFlag | (Optional) Specifies whether the value of this parameter can contain sensitive data, like a password. Valid values: true, false (default) When a parameter is marked as sensitive, it is displayed as masked in the Pod listing page. |
type | (Optional) Specifies the type of the parameter. The valid values are String, Integer and Address. String means any the values can be any alpha-numeric string. Integer means the values need to be integer. Address means the values need to be a valid IP address. |
paramBlueprints Schema
<paramBlueprints>
<!-- see <paramBlueprint schema -->
</paramBlueprints>Description: Each paramBlueprints tag consists of zero or more paramBlueprint tags.
podBlueprint Schema
<podBlueprint>
<!-- ========= Identity =============================================== -->
<diagramLink></diagramLink>
<legacyVersion></legacyVersion>
<name></name>
<!-- ========= Resources: Address Ranges ============================== -->
<addressRangeBlueprints>
<!-- see addressRangeBlueprint schema -->
</addressRangeBlueprints>
<!-- ========= Resources: Address Pools =============================== -->
<addressPoolBlueprints>
<!-- see addressPoolBlueprint schema -->
</addressPoolBlueprints>
<!-- ========= Resources: VLAN Pools ================================== -->
<vlanPoolBlueprints>
<!-- see vlanPoolBlueprint schema -->
</vlanPoolBlueprints>
<!-- ========= Resources: VLANs ======================================= -->
<vlanBlueprints>
<!-- see vlanBlueprint schema -->
</vlanBlueprints>
<!-- ========= Resources: Integer Pools =============================== -->
<integerPoolBlueprints>
<!-- see integerPoolBlueprint schema -->
</integerPoolBlueprints>
<!-- ========= Model: NIC Segments ==================================== -->
<nicSegmentBlueprints>
<!-- see nicSegmentBlueprint schema -->
</nicSegmentBlueprints>
<!-- ========= Model: Simple Parameters =============================== -->
<paramBlueprints>
<!-- see paramBlueprint schema -->
</paramBlueprints>
<!-- ========= Model: Nodes =========================================== -->
<nodeBlueprints>
<!-- see nodeBlueprint schema -->
</nodeBlueprints>
<!-- ========= Model: Pairs =========================================== -->
<pairBlueprints>
<!-- see pairBlueprint schema -->
</pairBlueprints>
</podBlueprint>Description:
The podBlueprint tag partially specifies how to create a pod, in an abstract way, so that the same blueprint specification can be reused across different environments and different hardware potentially. The partial specification of the pod is supplemented with additional input from the user for the name of the pod instance to create and the specifics of his physical environment and hardware in the pod creation wizard.
Children:
| Tag | Description |
|---|---|
addressPoolBlueprints | Consists of zero or more addressPoolBlueprint tags. See addressPoolBlueprint schema. |
addressRangeBlueprints | Consists of zero or more addressRangeBlueprint tags. See addressRangeBlueprint schema. |
balancedParamBlueprints | Consists of zero or more balancedParamBlueprint tags. See balancedParamBlueprint schema. |
diagramLink | (Optional) Specifies the URL linking to a diagram showing the physical topology for the pod. |
integerPoolBlueprints | Consists of zero or more integerPoolBlueprint tags. See integerPoolBlueprint schema. |
legacyVersion | The legacyVersion optional tag specifies the version of BMC Network Automation logic to use when naming port types within the hypervisor switch. Prior to 8.1.01, port profiles in switches were named using VLAN ID. However after 8.1.01 port profiles are created using the port type name. Assigning this tag a value prior to 8.1.01 (say "8.1.00") causes BMC Network Automation to use the legacy convention of naming the port type within the switch using its VLAN ID, rather than the name defined in the model. Assigning the tag a value of 8.2.01 or later (or leaving it unspecified), will cause BMC Network Automation to use the current logic of naming the port type within the switch using the name defined in the model. |
name | Identifies the pod blueprint. The name can include only alphanumeric characters. It cannot include symbols or special characters such as a single quote (') or dollar sign ($). |
nicSegmentBlueprints | Consists of zero or more nicSegmentBlueprint tags. See nicSegmentBlueprint schema. |
nodeBlueprints | Consists of one or more nodeBlueprint tags. See nodeBlueprint schema. |
pairBlueprints | Consists of zero or more pairBlueprint tags. See pairBlueprint schema. |
paramBlueprints | Consists of zero or more paramBlueprint tags. See paramBlueprint schema. |
vlanPoolBlueprints | Consists of zero or more vlanPoolBlueprint tags. See vlanPoolBlueprint schema. |
vlanBlueprints | See the vlanBlueprints tags table. See vlanBlueprint schema. |
portTypeBlueprint Schema
<portTypeBlueprint>
<description></description>
<name></name>
<nameWithinSwitch></nameWithinSwitch>
<nicSegmentName></nicSegmentName>
</portTypeBlueprint> Description:
Each portTypeBlueprint specifies information about one of the pod level virtual port types (that is, port profiles or port groups) which are assumed to already be present on this hypervisor switch. A pod level virtual port type can be used by any container in the pod to create virtual ports for NICs of VMs provisioned in that container.
Children:
| Tag | Description |
|---|---|
description | (Optional) Reminds the user of the purpose of the port type when populating its value in the pod creation wizard, or when viewing its value later in the pod viewer. |
name | Specifies a name for the port, which is unique among port types within the node. This is the name of the port type in the BMC Network Automation model, which may or may not be the same as the nameWithinSwitch value. |
nameWithinSwitch | Represents name of the port in switch. This should be non-null. The user may specify more complicated naming patterns in the nameWithinSwitch tags including references to any ${pod.}, ${eval.} and ${exec.*} parameters. |
nicSegmentName | Represents name of the NIC segment this port type connects to the switch. |
portTypeBlueprints Schema
<portTypeBlueprints>
<!-- see <portTypeBlueprint schema -->
</portTypeBlueprints>Description: Each portTypeBlueprints tag consists of zero or more portTypeBlueprint tags.
version Schema
<version>
<maint></maint>
<major></major>
<minor></minor>
</version>Description:
The version tag specifies the BMC Network Automation version which this PodBlueprint was created for.
Children:
| Tag | Description |
|---|---|
maint | Specifies the maintenance number portion of the BMC Network Automation build version. |
major | Specifies the major number portion of the BMC Network Automation build version. |
minor | Specifies the minor number portion of the BMC Network Automation build version. |
vlanBlueprint Schema
<vlanBlueprint>
<vlanName></vlanName>
<vlanPoolName></vlanPoolName>
</vlanBlueprint>Description:
Each vlanBlueprint tag partially specifies how to acquire a pod level VLAN from one of our VLAN pools. The partial specification of the VLAN in this tag is supplemented with additional input from the user for the specific ID to use in the pod creation wizard page.
Unlike the VLANs specified in ContainerBlueprints, where the ID involved is acquired from the VLAN pool on a first come first serve basis, the IDs for these pod level VLANs are specified by the user at pod creation time.
The difference between these pod level VLANs and VLANs which are marked as excluded by the user when creating the VLAN pool, is that these VLANs can be referenced as substitution parameters in the templates used to configure containers (for example, "${pod.vlans[My Pod Level VLAN]}". Pod level VLANs therefore typically represent VLANs for management networks which container servers can be attached to.
Children:
| Tag | Description |
|---|---|
vlanName | Specifies a way to uniquely identify this VLAN among the pod level VLANs. |
vlanPoolName | Specifies which vlan pool to acquire this VLAN from. |
vlanBlueprints Schema
<vlanBlueprints>
<!-- see <vlanBlueprint schema -->
</vlanBlueprints>Description: Each vlanBlueprints tag consists of zero or more vlanBlueprint tags.
vlanPoolBlueprint Schema
<vlanPoolBlueprint>
<defaultEndNum></defaultEndNum>
<defaultExtendedFlag></defaultExtendedFlag>
<defaultShareableFlag></defaultShareableFlag>
<defaultStartNum></defaultStartNum>
<name></name>
</vlanPoolBlueprint>Description:
Each vlanPoolBlueprint tag partially specifies how to create a VLAN pool. A VLAN pool defines a set of VLAN IDs that each container on the pod can acquire entries from. The partial specification of the pool in this tag is supplemented with additional input from the user for specific IDs within the set to mark as excluded that cannot be acquired by containers (for example, VLANs already in use for some purpose), in the pod creation wizard page.
Children:
| Tag | Description |
|---|---|
defaultEndNum | Specifies an initial value to present for the upper limit (inclusive) for the pool in the pod creation wizard page (you can override this initial value). |
| defaultExtendedFlag | Controls whether the pool should be initially flagged as extendable or not when the pod creation wizard page is presented for creating the pool (you can override this initial value in the wizard). If a pool is flagged as extendable (a pool supporting VXLAN), the VLAN pool range is from 0 to 224, as compared to the standard VLAN pool, which has pool range from 0 to 4096. |
| defaultShareableFlag | Controls whether the pool should be initially flagged as shareable or not when the pod creation wizard page is presented for creating the pool (you can override this initial value in the wizard). If a pool is flagged as shareable, multiple pods are allowed to reserve the same pool from IPAM, with each pod sharing the same copy. |
defaultStartNum | Specifies an initial value to present for the lower limit (inclusive) for the pool in the pod creation wizard page (you can override this initial value). |
name | Specifies a way to uniquely identify this VLAN pool within the pod. |
vlanPoolBlueprints Schema
<vlanPoolBlueprints>
<!-- see <vlanPoolBlueprint schema -->
</vlanPoolBlueprints>Description: Each vlanPoolBlueprints tag consists of zero or more vlanPoolBlueprint tags.
Comments
Log in or register to comment.