Reprovisioning network containers in BMC Network Automation

The topics in this section contain information about reprovisioning network containers in BMC Network Automation.

Notes

The reprovision operation is limited to adding and updating existing components.
You cannot add a firewall or load balancer node to an existing container. You can add a new firewall interface or a new load balancer interface to an existing network container, if that container has an existing firewall or load balancer node.
Deletion of components in the network container blueprint is not allowed during reprovisioning. If a component is deleted in the network container blueprint used to reprovision a container, BMC Network Automation detects those deletions, issues an appropriate error message, and stops the reprovision attempt.

Overview

The reprovisioning operation allows you to update a network container structure by adding new components to the container or updating existing entities in the container using new revision of the network container blueprint. The new components are added to the blueprint by editing its XML content externally and assigned a new revision number. The revised network container blueprint is imported into the system. The network container structure is updated with the new network container blueprint using reprovision operation. This gives the ability to scale the container by adding new components, such as NICs, VLBs, and VFWs. The reprovision operation is limited to adding and updating existing components. Deletion of components in the network container blueprint is not allowed during reprovisioning. If a component is deleted in the network container blueprint used to reprovision a container, BMC Network Automation detects those deletions, issues an appropriate error message, and aborts the reprovision attempt.

Container reprovisioning is a potentially complex operation because this involves modifying a production container in which there could be existing VMs. Therefore, BMC highly recommends that you test your reprovisioning process thoroughly in a local sandbox system before trying on production system. Also, BMC recommendeds that you build as much scalability into the original network container blueprint as possible, and just toggle the dynamic components in the network container rather than adding entirely new components to the network container using the reprovisioning process.

Components affected during a reprovision operation

The following schema are affected during a reprovision operation.

Addition of the revisionNum tag

The containerBlueprint schema now supports a revisionNum tag which is initialized to 0. The network container blueprints used for reprovisioning will have revisionNum updated appropriately.

Tags that can be updated in a revised network container blueprint

The following table summarizes the network container components tags that can be updated from a new revision of the network container blueprint during a reprovision operation.

Parent tag	Element tag	Updateable tag
configureActionInfoBlueprint		condition
addressSpaceBlueprint		condition
addressBlueprint		condition
integerBlueprint		condition
vlanBlueprint		condition
addressPoolBlueprint		condition
nicSegmentBlueprint	xsi:type="containerNicNetworkSegmentBlueprint"	description
nodeBlueprint		description numVrfs
externalNetworkSegmentBlueprint		description
managedInterfaceBlueprint		description
poolTypeBlueprint		description
configureActionInfoBlueprint	xsi:type="mergeActionInfoBlueprint"	name templateGroups item
vipSegmentBlueprint		description
portTypeBlueprint		description

Entities that can be fully re-populated as part of reprovisioning

The following table summarizes existing entities in container that can be fully re-populated if they are in certain states specified below. The table lists the container entity name. Also it lists blueprint element name (blueprint ID) used to identify the entity in a container. Each row in this table should be read as below. For example, the name element of the addressSpaceBlueprint tag in the container blueprint is used to uniquely identify an address space in a container. All attributes of AddressSpace, except the name element can be re-populated, if it is in the NOT_ACQUIRED state. This is used to correct blueprint authoring errors during reprovisioning.

Entity	State	Blueprint ID	Parent tag
AddressSpace	NOT_ACQUIRED	name	addressSpaceBlueprint
AcquiredVlan	NOT_ACQUIRED	name	vlanBlueprint
ContainerAddressPool	NOT_ACQUIRED	name, linkId	addressPoolBlueprint
AcquiredAddress	NOT_ACQUIRED	addressName	addressBlueprint
AcquiredInteger	NOT_ACQUIRED	integerName	integerBlueprint
ExternalNetworkSegment	DISABLED	name	externalNetworkSegmentBlueprint
ContainerNicNetworkSegment	DISABLED	name	nicSegmentBlueprint with these xsi types: xsi:type="containerNicNetworkSegmentBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
VipNetworkSegment	DISABLED	name	vipSegmentBlueprint
FirewallInterface	DISABLED	name	managedInterfaceBlueprint
LoadBalancerPoolType	DISABLED	name	poolTypeBlueprint
VirtualPortType	DISABLED	name	portTypeBlueprint
NetworkPath	DISABLED	name	networkPathBlueprint
ContainerVfw	DISABLED	guestNodeName	virtualGuestBlueprint with this xsi type: xsi:type="containerVfwBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ContainerVlb	DISABLED	guestNodeName	virtualGuestBlueprint with these xsi types: xsi:type="containerVlbBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
MergeActionInfo	STATE_NOT_APPLIED	name or <templateGroups> <item>TemplateGroupName</item> </templateGroups>	configureActionInfoBlueprint unconfigureActionInfoBlueprint createGuestActionInfoBlueprint initGuestActionInfoBlueprint destroyGuestActionInfoBlueprint createNatActionInfoBlueprint removeNatActionInfoBlueprint
CustomActionInfo	STATE_NOT_APPLIED	name or guid	configureActionInfoBlueprint unconfigureActionInfoBlueprint createGuestActionInfoBlueprint initGuestActionInfoBlueprint destroyGuestActionInfoBlueprint createNatActionInfoBlueprint removeNatActionInfoBlueprint
ExternalScriptActionInfo	STATE_NOT_APPLIED	name or guid	configureActionInfoBlueprint unconfigureActionInfoBlueprint createGuestActionInfoBlueprint initGuestActionInfoBlueprint destroyGuestActionInfoBlueprint createNatActionInfoBlueprint removeNatActionInfoBlueprint

Tags that can be added in a revised network container blueprint

The following table summarizes new entities that can be created and added to a network container from a new revision of the network container blueprint during a reprovision operation. The table lists the blueprint element names.

Note

If an addable tag is present in the previous version of the network container (for example, in revision 0), and it is deleted in the revised network container blueprint, BMC Network Automation throws appropriate error message and reprovision operation is aborted.

Parent tag	Element tag	Addable tag
containerBlueprint		addressSpaceBlueprint
containerBlueprint		addressPoolBlueprint
containerBlueprint		addressBlueprint
containerBlueprint		externalNetworkSegmentBlueprint
containerBlueprint		integerBlueprint
containerBlueprint		vlanBlueprint
containerBlueprint		nicSegmentBlueprint xsi:type="containerNicNetworkSegmentBlueprint"
containerBlueprint		nodeBlueprint
nodeBlueprint		addressBlueprint
nodeBlueprint		configureActionInfoBlueprint
nodeBlueprint		unconfigureActionInfoBlueprint
containerBlueprint		natTypeBlueprint
natTypeBlueprint		addressTranslatorBlueprint <!-- new adress translator>
addressTranslatorBlueprint		addressPoolName <!-- new address pool>
nodeBlueprint	xsi:type="containerHypervisorSwitchBlueprint"	portTypeBlueprint
virtualGuestBlueprint	xsi:type="containerVfwBlueprint"	managedInterfaceBlueprint
virtualGuestBlueprint	xsi:type="containerVlbBlueprint"	poolTypeBlueprint
poolTypeBlueprint		routeDomainId
containerBlueprint		networkPathBlueprint
networkPathBlueprint		servicedNodeName
containerBlueprint		pairBlueprint
pairBlueprint		addressBlueprint
containerBlueprint		vipSegmentBlueprint
containerBlueprint		vrfIdBlueprint
containerBlueprint		zoneBlueprint
zoneBlueprint		nicSegmentBlueprint xsi:type="containerNicNetworkSegmentBlueprint"
zoneBlueprint		vipSegmentBlueprint

Reprovisioning component change example

The following example is meant to clarify the affect of reprovisioning on network container components. Let us consider reprovisioning a container to add a new VLB to a sample dynamic container with edge and access nodes servicing a single NIC segment (AccessA). The following steps are involved in provisioning a network container with the original network container blueprint:

Created container with edge switch node and and access switch node.
Acquired vlan-A
Configured edge layer to connect to vlan-A
Configured access layer to connect to vlan-A

The original deprovisioning logic would be following:

Unconfigure access layer to no longer connect to vlan-A
Unconfigure edge layer to no longer connect to vlan-A
Release Vlan-A
Delete container

The following should happen to reprovision a network container to add a services layer:

The revision number (revisionNum) of container blueprint with new VLB in the services layer will be set to 1
Add a service switch node and LB host node (with a VLB guest node that is initially disabled) to the network container
Unconfigure edge layer to stop using vlan-A
Acquire vlan-B
Configure edge layer to connect to vlan-B
Configure services layer to connect it to vlan-A and vlan-B

The following should happen when a new container is provisioned now.

Create container with edge switch node, service switch node, LB host node (with a VLB guest node that is initially disabled), and access switch node
- Acquire vlan-A and vlan-B
- Configure edge layer to connect to vlan-B
- Configure service layer to vlan-A and vlan-B
- Configure access layer to connect to vlan-A
The logic to deprovision either of the containers will be the same as shown here.
- Unconfigure access layer to no longer connect to vlan-A
- Unconfigure service layer to no longer connect to vlan-A or vlan-B
- Unconfigure edge layer to no longer connect to vlan-B
- Release vlan-A and vlan-B
- Delete container

The revised version of the blueprint needs to be usable both for reprovisioning existing containers, and provisioning new ones. To handle this, you define special reprovisioning actions within the blueprint. These actions will be used to reconfigure devices during reprovisioning, but they will not be used during normal provisioning.

When reprovisioning a network container, it migrates from its current version (called the source revision number) to the network container blueprint version (called the target revision number). Reprovisioning actions are tagged with the source and target revision numbers that they are intended to migrate between.

In the revised version of the network container blueprint, the following changes would have been made:

New nodes added:
- Services switch node
- LB host node (with guest VLB node)
New resources added:
- Vlan-B
New reprovisioning actions added (source = revision 0, target = revision 1):
- Unconfigure edge layer to stop using vlan-A
- Configure edge layer to connect to vlan-B
- Configure service layer to connect it to vlan-A and vlan-B
Old provisioning actions dropped:
- Configure edge layer to connect to vlan-A
New provisioning actions added:
- Configure edge layer to connect to vlan-B
- Configure service layer to vlan-A and vlan-B
Old deprovisioning actions dropped:
- Unconfigure edge layer to no longer connect to vlan-A
New deprovisioning actions added:
- Unconfigure service layer to no longer connect to vlan-A or vlan-B
- Unconfigure edge layer to no longer connect to vlan-B

Changes to the network container blueprint schemas

The sections that follow describe the changes to the network container blueprint schemas to support reprovisioning operations. See Container blueprint XML reference.

Changes to the containerBlueprint schema

The revisionNum tag was added to the containerBlueprint schema. The revisionNum tag indicates the revision number of the network container blueprint. This tag is used in reprovisioning operations. The default value is 0.

Changes to the configureActionInfoBlueprint and unconfigureActionInfoBlueprint schemas

The sourceRevisionNum and targetRevisionNum tags have been added to the configureActionInfoBlueprint and unconfigureActionInfoBlueprint schemas that use the following xsi types:

xsi:type=”customActionInfoBlueprint”
xsi:type=”externalScriptActionInfoBlueprint”
xsi:type=”mergeActionInfoBlueprint”

These revision tags can be specified for one-time reprovisioning actions.

<configureActionInfoBlueprint xsi:type="mergeActionInfoBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <name>FTConfigBE_FWH.V0_TO_V1</name>
    <sourceRevisionNum>0</sourceRevisionNum>
    <targetRevisionNum>1</targetRevisionNum>
    <templateGroups>
         <item>FTConfigBE_FWH.V0_TO_V1</item>
    </templateGroups>
</configureActionInfoBlueprint>

While the network container is being reprovisioned, the action schemas that have sourceRevisionNum set to the network container revision number and targetRevisionNumber set to the network container blueprint revision number are run as part of configure and unconfigure actions for the reprovisioning job.