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.

Configuring a reprovisioning operation in BMC Network Automation for network containers


This topic contains information about configuring a reprovisioning operation for network containers in BMC Network Automation.

Failed to execute the [excerpt-include] macro.

The ContainerBlueprintService reprovisionContainer2 method

In BMC Network Automation, you use the ContainerBlueprintService reprovisionContainer2 method to reprovision a network container. The method takes the following inputs:

  • containerBlueprintName: The blueprint name additionally carries an optional revision number. For example, Large Gold Container Blueprint#1 specifies to reprovision a container with revision 1 of Large Gold Container Blueprint. If the revision number is not specified, the last revision of the blueprint is used.
  • containerName
  • restrictedFlag: This flag indicates whether non-reversible content should be added during container reprovisioning. For details, see Restricted Reprovisioning Mode.

Irrespective of the defaultEnabledFlag setting for the new components in the revised blueprint, the components are always added in a disabled state initially, and must 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 the new revision of the container blueprint.
  2. If restrictedFlag is set to true, BMC Network Automation checks whether any of the content added would lead to resources being acquired/released, or config/unconfig actions being executed, by an ensuing "do-nothing" modify operation. If any such pending side-effects are detected, the reprovision operation is aborted because it violates the constraints of restricted mode reprovisioning.
  3. If the above steps are successful, update the revision number of the container to the one specified in the blueprint.

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.

If an error occurs during reprovisioning, the database transaction that is in progress is abandoned and no changes are made.

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]}&nbsp;${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}

 

Note

The newly added NIC segment is in disabled state. The reprovision operation should be followed by a corresponding modify operation to enable the NIC segment.

 

Failed to execute the [excerpt-include] macro.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*