| Oracle® Communications IP Service Activator Configuration Development Kit Guide Release 7.2 E47724-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications IP Service Activator Configuration Development Kit Guide Release 7.2 E47724-01 |
|
|
PDF · Mobi · ePub |
This chapter provides a general explanation of driver scripts and how they can be used.
A driver script is a short program, written in the Python programming language, which is used to directly configure a device via the Oracle Communications IP Service Activator device drivers. Python allows the use of loops and if/then statements when generating device commands.
Scripts can be created directly from within the IP Service Activator user interface (client) and are stored in the system database. These scripts can then be associated with specific targets, such as a device or an interface. For each object that the script is applied to, the device driver executes the script and generates and applies the configuration. The timing of the configuration is dependent on control information, which is defined as part of the script.
A driver script is divided into five sections:
Preamble section: contains variables required in the rest of the script.
Behavior section: includes parameter definitions and scheduling information which define where and when a script is applied.
Common section (optional): defines functions that can be used more than once in the script, such as finding an IP address or returning the device status.
Install section: contains code that is run when a script is associated with an object in order to configure commands on a device.
Remove section (optional): contains code that is run when a script is disassociated from an object in order to remove configuration from a device.
There are five different types of script, each with a particular target:
Device: applies commands at device level
Interface: applies commands at interface level
Sub-interface: applies commands at sub-interface level
ATM PVC: applies commands to ATM PVCs
Frame Relay PVC: applies commands to Frame Relay PVCs
In common with rules and PHB groups, driTaver scripts must be allocated roles in order to define the points in the network at which they will be applied.
All scripts must have one or more device roles. Interface, sub-interface and PVC scripts must also have one or more interface roles assigned.
A script is only implemented on objects that have the same role. For example, a Device script with the role of Core device is only applied on those devices that are assigned the role of Core. For a Sub-interface script, the device, interface and sub-interface roles must all match for the script to be applied. For information about using roles in policy elements, see IP Service Activator QoS User's Guide.
Scripts can be associated with objects at different levels of the hierarchy and are then applied to all relevant objects by a process of inheritance. For example, if a sub-interface script is associated with a network object, it is applied to all sub-interfaces on devices within that network that have the correct role setting.
When the device driver runs the script, a separate concrete script is created for each instance.
You can associate scripts with the following objects:
Customers
VPNs
Sites
Networks
Devices
Interfaces
Sub-interfaces
PVC endpoints
Figure 2-1 shows a diagram of device script inheritance.
Note:
In situations where more than one script applies to an object, no priority ordering is carried out. You should ensure that multiple scripts do not result in conflicts.Each script runs in a specific context. This ensures that the writer of a script can assume the existence of a number of certain defined objects, and set up particular parameters. For example, at the device level, all device-specific information, such as IP address, device type and number of interfaces, is automatically available. At the interface level, all interface-specific information is available in addition to device details.
Each object that can have a driver script applied to it can have additional commands defined that set variables to specific values. This enables a generic script to have a different effect depending on which router, interface or PVC is being configured. For example, the local context for a Frame Relay interface could set values for the CIR, Bc and Be parameters, which could then be used later for Frame Relay Traffic Shaping, using a Sub-interface script applied to the network level.
Note:
A maximum of 512 characters can be included in an object's local context definition.In addition to an object's local context, each object inherits specific context from its parent objects. For example, a PVC endpoint can potentially inherit context defined for its parent sub-interface device and network. Figure 2-1 shows the way in which driver scripts are inherited.
As for any other IP Service Activator configuration, driver scripts are implemented when a transaction is committed, resulting in configuration being propagated to network devices.
Users can define whether a driver script is run before or after any other configuration changes applied at the same time.
A script can be scheduled to run once, in which case it will be run when the transaction is committed, or repeatedly, in which case it will be run on the next commit and every subsequent commit until it is removed from the object.
When a script is scheduled to run once, users can specify to create concretes only once, on first execution of the script. When this attribute is set to true, it prevents re-running the script and recreating concretes after a driver restart, or after remanaging the device (unmanage then manage), or after role reassignment.
It is also possible to specify that a script is run when the system detects that a device has restarted. In this case, after the transaction containing the script application has been committed it will run whenever the device restarts, without the need for a further commit.
The Install section of a driver script is run when a script is associated with one or more objects.
The Remove section of a driver script is run when a script is set to disabled or unlinked from an object.
Note:
If a script is set to run once only, and not when a device is restarted, the Remove section can never be run as the device driver does not preserve the script. If a script is set to run once only and run on a restart, then it is possible for the Remove section to be run.A driver script can be applied to an object either by being directly linked or as a result of inheritance. The various sections of the script and its context (local and inherited) are combined to produce a Python script (that is, a concrete driver script object) that is run in the device driver against the selected device or a component of the device.
Note:
Scripts are not processed by the IP Service Activator policy server. This means that they are not checked or validated in any way.When a script is to install configuration, it is constructed and run in the following order:
Preamble section
Inherited context
Local context
Common section
Install section
Figure 2-2 shows how a concrete driver script to apply configuration is constructed.
Parameters defined in the local context always override those inherited from parent objects.
The information in the Behavior section does not form part of the executed concrete script, but is used to define where and when the script is run.
The script returns a result code, which will be OK unless appropriate tests are put in place as part of the script.
When a script is designed to remove configuration, it is constructed and run in the following order:
Preamble section
Inherited context
Local context
Common section
Remove section
Figure 2-3 shows how a concrete driver script to remove configuration is constructed.
Parameters defined in the local context always override those inherited from parent objects.
The information in the Behavior section does not form part of the executed concrete script, but is used to define where and when the script is run.
The script returns a result code, which will be OK unless appropriate tests are put in place as part of the script.
For each device that it manages, the driver allocates an area of memory that may be accessed by any Python scripts that are applied to that device. This is referred to as the shared data area or shared area. Information may be stored in this area as a Python dictionary or as a class-based structure. If a class-based structure is required, a Python module must be written that defines the data structure and passed to the device driver using a command-line option.
The shared data area supports the interchange of data between scripts and has a wide range of applications, for example, facilitating script ordering or optimizing re-use of basic functions used across scripts.
For more information, see "Sharing Data Between Scripts".
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
