Configuring a reprovisioning operation for network containers

Reprovisioning operation

Reprovisioning can be accomplished using the ContainerBlueprintService reprovisionContainer method. The method takes following inputs:

1. Container blueprint name. The blueprint name additionally carries an optional revision number. For example, Large Gold Container Blueprint#1 specifies to reprovision container with revision 1 of Large Gold Container Blueprint. If the revision number is not specified, the last revision of blueprint is used.
2. Container name
3. Runtime parameters if any required by reprovisioning templates
4. Ignore errors flag which when set to true ignores error during unconfigure or configure steps during reprovisioning. If the flag is set to false and if there is an error during the unconfigure stage, the error is returned back to the caller. Similarly, if there is an error during the configure stage, the error is returned back to the caller and the network container revision number is not updated.

The resources acquired during reprovisioning are limited to only infrastructure resources. Resources required for VM provisioning such as address spaces, address pools cannot be acquired during reprovisioning as the operation above does not support overrides.

The new togglable components added during reprovisioning, such as NIC segments and VLBs, should be in disabled state. Those components should be enabled by a subsequent modify operation.

The sequence that is executed when reprovisioning a container involves the following steps:

1. Update the container structure based on the additions or modifications in new revision of the container blueprint.
2. Execute one time unconfigure reprovisioning actions based on source and target revision numbers.
3. Release resources whose conditional no longer evaluates to true.
4. Acquire resources whose conditional now evaluates to true.
5. Execute one time configure for reprovision actions based on source and target revision numbers.
6. Update the revision number of the container to one specified in the blueprint if the above five steps are successful.

If BMC Network Automation finds that the source network container contains a component that is missing from the network container blueprint used to perform the reprovisioning operation, BMC Network Automation issues an exception, and the operation is stopped. If an error occurs during this sequence, BMC Network Automation sends the error back to the caller. The only exception is if the ignore errors flag has been set to true, any errors during step 2 and step 5 are logged in the BMC Network Automation application server and not propagated back to the caller.

If an error occurs during reprovisioning, the network container is left in partially reprovisioned state. BMC Network Automation does not attempt to undo partial changes made if there is a failure during reprovisioning. The administrator must recover by troubleshooting the problem and retrying the reprovisioning operation.

Reprovisioning network container blueprint changes example

The following example illustrates the changes that you would make to a network container blueprint to add a new NIC [AccessC] to sample dynamic container blueprint and reprovision the container.

1. Add the new revision number to the network container blueprint.

             <revisionNum>1</revisionNum>
   

2. Add the new address pool blueprint schema.

       <addressPoolBlueprint>
           <condition>-EXISTS- container.nicSegments[AccessC]</condition>
           <name>AccessC</name>
           <rangeBlueprintName>Data</rangeBlueprintName>
       </addressPoolBlueprint>
   

3. Add the new vlan blueprint.

      <vlanBlueprint>
          <condition>-EXISTS- container.nicSegments[AccessC]</condition>
          <vlanName>AccessC</vlanName>
          <vlanPoolName>Data</vlanPoolName>
      </vlanBlueprint>
   

4. Add the new NIC segment blueprint.

      <nicSegmentBlueprint xsi:type="containerNicNetworkSegmentBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
          <addressPoolName>AccessC</addressPoolName>
          <customerFlag>true</customerFlag>
          <defaultEnabledFlag>false</defaultEnabledFlag>
          <lockedFlag>false</lockedFlag>
          <managementFlag>false</managementFlag>
          <name>AccessC</name>
          <networkName>AccessC</networkName>
          <tag>Purpose[Application]</tag>
          <vlanName>AccessC</vlanName>
      </nicSegmentBlueprint>
   

5. Add the new network path blueprint.

      <networkPathBlueprint>
          <endpoint1Name>External</endpoint1Name>
          <endpoint2Name>AccessC</endpoint2Name>
          <name>External-AccessC</name>
      </networkPathBlueprint>
   

6. Modify the edge node to specify a gateway address, and configure and unconfigure action items.

      <addressBlueprint>
          <addressName>GatewayC</addressName>
          <addressPoolName>AccessC</addressPoolName>
          <condition>-EXISTS- container.nicSegments[AccessC]</condition>
          <gatewayFlag>true</gatewayFlag>
          <poolPosition></poolPosition>
      </addressBlueprint>
   
      <configureActionInfoBlueprint xsi:type="mergeActionInfoBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
          <condition>-EXISTS- container.nicSegments[AccessC]</condition>
          <name>Edge-C</name>
          <templateGroups>
              <item>SampleDynamicConfigureEdge-C</item>
          </templateGroups>
      </configureActionInfoBlueprint>
   
      <unconfigureActionInfoBlueprint xsi:type="mergeActionInfoBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
          <name>Edge-C</name>
          <templateGroups>
              <item>SampleDynamicUnconfigureEdge-C</item>
          </templateGroups>
      </unconfigureActionInfoBlueprint>
   

7. Modify the hypervisor node to specify the port type, and configure and unconfigure action items for AccessC.

      <configureActionInfoBlueprint xsi:type="mergeActionInfoBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
           <condition>-EXISTS- container.nicSegments[AccessC]</condition>
           <name>Access-C</name>
           <templateGroups>
               <item>SampleDynamicConfigureAccess-C</item>
           </templateGroups>
      </configureActionInfoBlueprint>
   
      <portTypeBlueprint>
           <name>AccessC</name>
           <nameWithinSwitch>$\{container.node.portTypes[AccessC].vlan}</nameWithinSwitch>
           <nicSegmentName>AccessC</nicSegmentName>
      </portTypeBlueprint>
   
      <unconfigureActionInfoBlueprint xsi:type="mergeActionInfoBlueprint" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
           <name>Access-C</name>
           <templateGroups>
               <item>SampleDynamicUnconfigureAccess-C</item>
           </templateGroups>
      </unconfigureActionInfoBlueprint>
   

8. Add the template group SampleDynamicConfigureEdge-C.

      interface vlan${container.vlans[AccessC]}
      ip address
      {container.node.addresses[GatewayC]} ${container.node.addresses[GatewayC].subnetMask.CIDR}
      no shutdown
      exit
   

9. Add the template group SampleDynamicUnconfigureEdge-C.

      no vlan ${container.vlans[AccessC]}
      no interface vlan${container.vlans[AccessC]}
   

10. Add the template group SampleDynamicConfigureAccess-C (shown for vswitch).

    port-profile ${container.node.portTypes[AccessC].name}
       switchport mode access
       switchport access vlan ${container.node.portTypes[AccessC].vlan}
       vmware port-group ${container.node.portTypes[AccessC].vlan}
       no shutdown
       state enabled
       exit
    

11. Add the template group SampleDynamicUnconfigureAccess-C.

       no port-profile ${container.node.portTypes[AccessC].name}
    

Restricted reprovisioning mode

The entities that can be added to container during reprovisioning operation can be restricted using a global property, restrictedReprovisioningMode. By default, the flag is set to true in the global.properties file, which disallows the addition of service nodes such as VLB or VFW, access switches, and external segments in network container blueprints, but allows everything else like address space or address pool or NIC network segments. Setting it to true also causes BMC Network Automation to skip the steps in the reprovisioning sequence involving changing resource states and executing actions to reconfigure devices, since those steps should not be necessary in the restricted context. If restricted mode is enabled and BMC Network Automation detects restricted entities in a network container blueprint used to reprovision a network container, the reprovisioning attempt is rejected. If this parameter is set to false, any entity can be added to a network container during reprovisioning.