Unsupported content

 

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

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.

Note

You can compare adjacent container blueprint versions by running a difference details report in the BMC Network Automation user interface. See Viewing the container blueprint listing in the BMC Network Automation on-line technical documentation. For example, if there are three revisions of the Large Gold Container Blueprint (0, 1, and 2), you can run the Container Blueprint Difference Details report for versions 0 and 1 or versions 1 and 2.

Was this page helpful? Yes No Submitting... Thank you

Comments