Cisco Provisioning Center User's Guide, 4.2
Change Management
Downloads: This chapterpdf (PDF - 215.0KB) | Feedback

Change Management

Table Of Contents

Change Management

Overview

Sessions

Transactions

Description

Transaction States

Change Requests

Description

Change Request States

Concurrent Transactions

Upload Request

Description

Upload Request States


Change Management


This chapter provides detailed information about Cisco Provisioning Center's change management features.

Overview

Change management is the set of features that help you manage the general process of deploying changes to your network. It is not specific to any particular type of managed element, but applies to the overall change process.

Sessions

A Cisco Provisioning Center session is analogous to a UNIX login session. You must start a session in order to access and manipulate the network. A single user may open and use multiple sessions which can be automated or interactive.

The Cisco Provisioning Center server can process requests from multiple user sessions. Each session is identified by a unique session ID which also defines the security permissions associated with the session.

Service objects and service elements are updated within the context of a session. The Session Manager is responsible for managing sessions with tasks such as creating and deleting sessions.

You manage the session for your flow-through applications by creating them as required, distributing work amongst the sessions, and terminating the sessions on exit.

When you are using the GUI, a session is assigned from pool of sessions when you log in from your browser and it is managed for you.

Transactions

Description

A transaction is the vehicle by which changes are applied to the network. It ensures that all changes to network configuration, applied to network elements through the equipment modules, are under change control. A transaction can contain a single change request (CRs) that alters the configuration of your network.

A session can have multiple transactions, and multiple transactions can be processed in parallel.

Transactions are opened automatically in response to requests to create, modify and delete Services and service elements. Transactions can also be controlled directly (explicitly started and stopped) when required.

Cisco Provisioning Center also provides the option to schedule Transactions to be applied to the network at a later date and/or time. The scheduling feature allows more efficient use of network resources. For example you can schedule the activation and modification of services around periods of network maintenance and administration.

All changes within a single transaction must succeed in order for the transaction to be applied and delivered to the network. Should any one change within the transaction fail, all changes in the transaction are rolled back.

Transaction States

Whenever you press the apply now button, a transaction is opened automatically. When you press the save button a new transaction will be opened automatically, unless there is one open already, in which case, your new change will be saved to the existing transaction.

Once you have opened a transaction, it will move through various states on its way to being applied successfully or abandoned.

Figure 3-1 Saving and Applying Transactions from the GUI

The following table describes available transaction states:

State
Description

Ready

The Create FTI command creates a new transaction and leaves it in the READY state.

While in the READY state, a transaction is available for use by any session. Transactions can be passed between sessions while in the READY state.

Transactions in the Ready state when Cisco Provisioning Center is restarted will be left in Ready state.

Current

A transaction may be opened from the READY state, or created and opened in a single step with AVcr start. The open session will see the transaction as CURRENT, while other sessions will see it as BUSY.

A transaction in the CURRENT state is opened when you click on the apply now or save button from the GUI.

A transaction in the CURRENT state is required to make changes to the database. When an object is modified, Cisco Provisioning Center automatically creates a pending version of the affected object and associates that version with the current transaction. When the transaction is closed, it returns to the READY state. The transaction may be closed and reopened indefinitely until all required pending configuration changes have been made.

If a Transaction is in the Current state within a session that terminates unexpectedly, then the Transaction will be closed and abandoned automatically.

Scheduled

Once a schedule time is specified, the transaction is set to SCHEDULED. The transaction will remain in the SCHEDULED state until the schedule time. At the schedule time, Cisco Provisioning Center will apply the transaction.

A transaction that is in the SCHEDULED state can be UNSCHEDULED, and returned to the READY state.

Busy

The transaction is BUSY if another session is using it, even to the originating session. The transaction will also become BUSY while it is being applied to the network.

Applied

Once all sites have been activated and confirmed, Cisco Provisioning Center will commit the changes to the database. Upon completion the transaction state is set to APPLIED.

Alert

The transaction can be ABANDONED from the READY, or CURRENT states - either by client request or if Cisco Provisioning Center detects a non-recoverable error.

Cisco Provisioning Center rolls back the network to its previous state and discards any pending objects in the database. During this activity the transaction passes through the ALERT state. This is normally a transitional state. A transaction that stays in this state for an extended period of time may require operator intervention.

Abandoned

Upon completing network rollback (which may or may not be complete) and database rollback (which will be complete) the transaction state is set to ABANDONED.


Figure 3-2 illustrates the transaction states and the functions or conditions that trigger the state transitions.

Figure 3-2 Transaction States

Change Requests

Description

Change requests manage changes to the network configuration. All changes that are sent from Cisco Provisioning Center to the network are in the form of a change request (CR). Change requests are used within a transaction to manage the requested change.

The transaction log contains complete details of the various states through which the CR passes on its way to the succeeded or rejected state.

CRs remain in the Cisco Provisioning Center database until they are explicitly deleted by the administrator, thus providing an audit of uploads. You should back up and delete these CRs periodically.

Change Request States

The GUI displays the change request states in the provisioning transaction window and in the transaction (audit) logs. Like a transaction, a change request passes through various states. These states are separate, but related to the transaction states. Figure 3-2 shows the transaction states with the corresponding change request states in parentheses.

State
Description

Created

The initial state of the change request.

Submitted

The CR is submitted for approval.

Opened

With the CR opened, updates made to the database representation will be associated with this CR.

When an object is modified, Cisco Provisioning Center automatically creates a pending version of that object and associates that version with the open CR. When the transaction closes the CR, the CR is in the APPROVED state. Transactions may close and reopen the same CR indefinitely until all required changes have been made.

Approved

The CR has been approved by the owner of the transaction. When a transaction is closed from the OPEN state (from the GUI or FTI), the CR is put it into the APPROVED state.

The transaction may now open the CR and begin updating the configuration of network elements included in this CR. When all updates for a given CR are complete, the transaction invokes the apply function to set the CR state to SCHEDULED. It is possible that the schedule function may also be used to set the CR state to SCHEDULED.

Processing

The CR is in the process of being applied. The CR state remains PROCESSING until all sites have SUCCEEDED. During processing the CR may temporarily enter a WAITING state while it waits for resources.

At the end of the processing state, if one or more sites fail or if any checks fail, then the CR is sent to the FAILED state.

Committing

Once all sites have been activated and confirmed, the system will commit the changes (i.e., make the pending versions of the network elements the current versions). During this activity the CR is in the COMMITTING state.

Succeeded

Once the CR has been committed, the CR state is set to SUCCEEDED.

Rejected

If errors are encountered during the processing or committing phases, Cisco Provisioning Center discards any updates, deletes the pending version of each updated network element, and rolls-back all sites to their previous states. During this activity, the CR is in the REJECTING state. Upon completion, the CR state is REJECTED.

Rejecting

All changes to the network are rolled back and any pending versions are discarded.

Failed

A CR is put into the FAILED state if the CR could not be processed because a site filed or a check failed.


Concurrent Transactions

Cisco Provisioning Center allows multiple transactions to be processed in parallel. However, you cannot have more than one transaction in the CURRENT state at any one time.

Cisco Provisioning Center has been enhanced to allow any combination of uploads and downloads (transactions) to occur in parallel, subject to certain rules.

Cisco Provisioning Center uses the concept of span locking to allow concurrent uploads and downloads. The effect of the span setting on a request is a measure of the number of objects that are affected by the request, and therefore how much of the Cisco Provisioning Center database needs to be locked while the request is being processed and committed.

Each UR and CR will be assigned a span setting, and a request whose span settings do not overlap will be allowed to execute in parallel. A request whose span setting conflicts with a request that is already processing will be queued until the processing request is complete.

Span locking is used for both uploads and downloads. Equipment modules that are not capable of sustaining concurrent downloads will set their span setting accordingly, and requests which include these equipment modules will be processed serially.

Upload Request

Description

In addition to change requests, change management includes upload requests. All uploaded configuration changes, which are applied to the Cisco Provisioning Center database through the equipment modules, are under change control.

All configuration changes associated with an upload are controlled by an upload request (UR). Each upload request has an associated audit log that shows the history of the upload.

Each UR is applied as a separate transaction. If any individual database change fails, all other changes are rolled back and the UR is left in the failed state. A successful UR is left in a succeeded state.

URs remain in the Cisco Provisioning Center database until they are explicitly deleted by the administrator, thus providing an audit of uploads. You must delete these URs periodically.

Upload Request States

Figure 3-3 illustrates the UR states and the functions and/or conditions that trigger the state transitions.

Figure 3-3 Upload Request States

The following table describes the UR states:

State
Description

Created

An administrator starts an upload manually, which creates a new UR and puts it into the CREATED state. After the information needed to perform the upload is provided to the UR, the UR state is set to PROCESSING and the upload begins.

Processing

The UR state remains PROCESSING until the upload is complete, updating all current versions of the network elements. During processing the UR may temporarily enter the WAITING state if it must wait for resources. At the end of the processing phase, the UR state is set to either SUCCEEDED or FAILED.

Succeeded

Upon completion, the UR state is set to SUCCEEDED.

Failed

If errors are encountered during the upload, Cisco Provisioning Center discards any database updates. The UR state is set to FAILED. An error dialog will pop up describing the error if the current transaction fails.