Important

   

Starting version 8.9.03, BMC Network Automation is renamed to TrueSight Network Automation. This space contains information about BMC Network Automation 8.9.02 and previous versions. For TrueSight Network Automation 8.9.03 and later releases, see the TrueSight Network Automation documentation.

Managing pods and containers from the BMC Network Automation CLI

The sections in this topic describe the following Pod and Container Management (PCM) functions that you can perform from the BMC Network Automation command line interface that are related to BMC Cloud Lifecycle Management:

To import and export PCM components

You can export the following components from one BMC Network Automation system into an XML file that you can then import into another BMC Network Automation system. You also can import components that you create manually.

  • Combo groups 
  • Conditions 
  • Container blueprints
  • Containers
  • Device security profiles
  • Dynamic fields
  • Global substitution parameters
  • Keywords 
  • Pod blueprints
  • Pods
  • Policies
  • Predefined jobs
  • Roles
  • Rules
  • Rule sets
  • Remote file servers
  • Templates

This topic describes how to export and import components using a script.

Import and export scripts

The scripts are available in the bcan-import-export-v.r.mm.zip file in the BCAN_HOME\public\bmc\bca-networks\extras directory. When the file is unzipped, the scripts are in the bin subdirectory. The lib subdirectory contains the libraries needed to run the scripts.

Note

The string v.r.mm is a substitute for the current version of the BMC Network Automation software.

Both Linux and Microsoft Windows scripts are available. For usage information, invoke any of the scripts with a -? option. This option displays the list of input parameters.

Note

  • You can export and import components only between BMC Network Automation application servers of the same version.
  • Dependent components that you are importing should already exist in the BMC Network Automation system. For more information, see Import dependencies.

Back to top

To export components using a script

Invoke the export.bat or export.sh command with the following options:

Option

Description

-?Displays help

-component component_name

Specifies the component to export:

Valid values:

  • ComboGroups
  • Conditions
  • Containers
  • ContainerBlueprints
  • DeviceSecurityProfiles
  • DynamicTypes
  • Keywords
  • PodBlueprints
  • Pods
  • Policies
  • PredefinedJobs
  • RemoteFileServers
  • Roles
  • Rules
  • RuleSets
  • SubstitutionParameters
  • TemplateGroups

-containerBlueprintName container_blueprint_name

(Optional) Specifies the full name of a container blueprint; do not use wildcards in the the container blueprint name.

This option is only applicable for template groups and can be optionally used to export template groups specified by the named container blueprint.

-file filename

Specifies the name of the export file

-fileEncoding encoding

(Optional) Specifies the character encoding to be used to when creating the output file during export

Valid values: UTF-16, UTF-8 (default)

Note: For UTF-8, the file should not contain Byte Order Mark (BOM) encoding because the Java APIs do not handle UTF-8 with BOM-encoded files.

-name "filter"

(Optional) Specifies the name of the component to export

You can use wildcards; for example, Bronze container.

The following option is only applicable to container blueprints:
The number of the revision to be exported can be specified as per the following format: <ContainerBlueprintName>#<RevisionNumber>
If no filter is specified when exporting container blueprints, all revisions of the container blueprints are exported.

-password password

Specifies the BMC Network Automation server password

-url URL

Specifies the BMC Network Automation server URL in the following format: https://<server>:<port>

-user username

Specifies the BMC Network Automation server user name

-v 
Prints detailed error stack trace

Import dependencies

A component might use or have dependency on other underlying components. Before you import a component, ensure that you import its underlying components. For more information about considerations and conditions while importing components, see the following table.

ComponentDependency description and other conditions
Combo groups

Components

  • Groups – The groups which comprise the combo group must be present in the destination system.
  • Dynamic fields – The dynamic fields associated with the combo group must be present in the destination system.
Conditions

Components

  • Keywords – The keywords used by the condition must be present in the destination system.
  • Devices – The devices for which the condition is applicable must be present in the destination system.
  • Groups – The groups for which the condition is applicable must be present in the destination system.
  • Realms – The realms for which the condition is applicable must be present in the destination system.
  • Dynamic fields – The dynamic fields associated with the condition must be present in the destination system.
Container blueprints

Components

  • Container blueprint template – The container blueprint template must be present in the destination system.
  • Custom actions – The custom actions (if used) in the container blueprint must be enabled in the destination system.
  • External script actions – The external script actions (if used) in the container blueprint must be enabled in the destination system.

Condition

  • If you had exported the container blueprint before installing BMC Network Automation and the <poolMask> tag existed, ensure that you change its value from dotted decimal format to CIDR format, otherwise, the import will fail.
Containers

Components

  • Container blueprint – The container blueprint must be present in the destination system.
  • Pod – The pod which the container belongs to must be present in the destination system.

Conditions

  • If a container with the same name already exists in the destination system, it must be deleted before a new one is imported.
  • If you had exported the container before installing BMC Network Automation and the <poolMask> tag existed, ensure that you change its value from dotted decimal format to CIDR format, otherwise, the import will fail.
Device security profiles

No dependencies

Condition

  • If a device security profile with the same name already exists on the destination system, that device security profile is overwritten.
Dynamic fields

These dependencies are applicable for only the configuration profiled (CAP) dynamic fields:

  • Devices – The devices with which the dynamic fields are associated must be present in the destination system.
  • Groups – The groups with which the dynamic fields are associated must be present in the destination system.
  • Realms – The realms with which the dynamic fields are associated must be present in the destination system
Global substitution parameters

Component

  • Dynamic fields – The dynamic fields associated with the global substitution parameter must be present in the destination system.
Keywords

Component

  • Dynamic fields – The dynamic fields associated with the keyword must be present in the destination system.
Pod blueprints

Condition

  • If you had exported the pod blueprint before installing BMC Network Automation and the <poolMask> tag existed, ensure that you change its value from dotted decimal format to CIDR format, otherwise, the import will fail.
Pods

Components

  • Pod blueprint – The pod blueprint must be present in the destination system.
  • Devices – The devices assigned to the pod must be present in the destination system.

Conditions

  • If a pod with the same name already exists in the destination system, it must be deleted before a new one is imported.
  • If you had exported the pod before installing BMC Network Automation and the <poolMask> tag existed, ensure that you change its value from dotted decimal format to CIDR format, otherwise, the import will fail.
Polices

Components

  • Devices – The devices for which the policy is applicable must be present in the destination system.
  • Groups – The groups for which the policy is applicable must be present in the destination system.
  • Realms – The realms for which the policy is applicable must be present in the destination system.
  • Keywords – The keywords being used by the policy must be present in the destination system.
  • Conditions – The conditions being used by the policy must be present in the destination system.
  • Users – If a notification is to be sent to a set of users, the same set of users must be present in the destination system.
Predefined jobs

Components

  • Devices – The devices on which the predefined job needs to be run must be present in the destination system.
  • Groups – The groups on which the predefined job needs to be run must be present in the destination system.
  • Realms – The realms on which the predefined job needs to be run must be present in the destination system. If you are importing a predefined job containing a span action with group as the span and the system contains groups with the same name in multiple realms, you must specify the realm name under the spanParams tag in the XML file being imported. If you do not specify a realm, a random group (as a span) gets associated with the job.
  • Rules – The rules being used in the predefined job actions must be present in the destination system.
  • Templates – When importing a predefined job containing a template (for example, Deploy to Active), the destination system should already have a template by that name. Alternatively, you can import the template, but import it prior to importing the predefined job, or add the template to the XML file that is being imported and place it before the predefined job.
Roles

Components

  • Dynamic fields – The dynamic fields associated with the role must be present in the destination system.
  • Custom action adpaters – The custom action adapter (if used) in the role must be present in the destination system.

Conditions

  • No users are associated with roles while importing or exporting roles.
  • You cannot add a new root role, or modify a role to be the root role while importing.
  • You can modify only the dynamic fields of an Administrator role while importing.
  • If a role with the same name already exists on the destination system, that role is overwritten.
  • The user who is importing a new role or the changes to an existing role must have rights to add or edit such a role.
    If you want to change the rights assigned to a role in the XML file, see the Javadoc documentation for the values that you can pass in the XML file. Note that you must log on to access the documentation. 

Rules

Components

  • Rule sets – The rule set which the rule belongs to must be present and enabled in the destination system.
  • Device types – The device types for which the rule is applicable must be enabled in the destination system.
  • Devices – The devices for which the rule is applicable must be present in the destination system.
  • Groups – The groups for which the rule is applicable must be present in the destination system.
  • Relams – The realms for which the rule is applicable must be present in the destination system.
  • Dynamic fields – The dynamic fields associated with the rule must be present in the destination system.
Rule sets

Components

  • Devices – The devices for which the rule set is applicable must be present in the destination system.
  • Groups – The groups for which the rule set is applicable must be present in the destination system.
  • Realms – The realms for which the rule set is applicable must be present in the destination system.
Remote file servers

Component

  • Dynamic fields – The dynamic fields associated with the remote file server must be present in the destination system.
Templates

Component

  • Dynamic fields – The dynamic fields associated with the template must be present in the destination system.

To import components using a script

Invoke the import.bat or import.sh command with the following syntax and options:

import options filename [filename ...]

Note

  • If you import components that already exist, BMC Network Automation deletes the existing component and adds the new one.

    BMC Network Automation does not merge the data of the existing component and the new component.
  • A container is tightly bound to a specific BMC Network Automation system. Rarely, when you export and import pods and containers from one system to another, imported job numbers will not map to the jobs in the system to which they are imported.

    A container is imported successfully if the target system does not contain any job at all or if no existing jobs match the ones present in the imported file. If the job numbers map and you click the links of an imported container, you would be looking at incorrect information.

The following options are available for this command:

Option

Description

-?Displays help

-fileEncoding encoding

(Optional) Specifies the character encoding to be used to read the input files during import

Valid values: UTF-16, UTF-8 (default)

Note: For UTF-8, the file should not contain BOM encoding because the Java APIs do not handle UTF-8 with BOM-encoded files.

-password password

Specifies the BMC Network Automation server password

-scope scope

(Optional) Specifies the import scope that designates the components to import

Valid values:

  • all – Default
  • new – Only imports components that are not already in the database
  • existing – Reimports components and overwrites those already in the database

-url URL

Specifies the BMC Network Automation server URL in the following format: https://<server>:<port>

-user username

Specifies the BMC Network Automation server user name

-v 
Prints detailed error stack trace

Replace filename with the names of one or more XML files that were exported from a BMC Network Automation server.

These file names can contain absolute or relative paths. If a file name contains a blank space, it must be enclosed in double quotation marks (").

You can also use wildcards (for example, *myfile.xml*).

Back to top

Related topic

Exporting and importing components using APIs

To manage containers using a script

You can use the container utilities script to provision, modify, and deprovision a container and add or remove a NIC, without involving BMC Cloud Lifecycle Management. This can be helpful when testing out a new container blueprint. For more information about this script, see Using the container utilities script.

Using the API

The BMC Network Automation Web Services API fully exposes the information in the underlying Pod and Container Management (PCM) engine model to facilitate customizations and automated testing. For more information about using API classes and methods to manage pods and containers, see Virtual Data Center API classes and methods.

Viewing the javadocs for the web services

Perform the following steps to view the javadocs for the BMC Network Automation web services:

  1. Unzip the most recent BCAN_INSTALL\BCA-Networks\public\bmc\bca-networks\extras\bcan-ws-clientapi-8.9.xx.zip file.
  2. Identify the destination directory for the .zip file.
  3. Navigate to the API_Destination_Directory \bcan-ws-clientapi\apidocs directory.
  4. Open the overview-frame.html file. A page displays that provides links to the various DTOs and web service APIs.
  5. Click the com.bmc.bcan.ws.shared link. A page displays that provides links to the javadocs for the various BMC Network Automation web services.

Back to top

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

Comments