The logical extension to detecting differences, as covered in the previous chapter, is what to do about it. Do you want to synchronize property values? Which value takes precedence, the one in Application Configuration Console, or the one in the external resource? Or do you want to go back to a fixed point in time when you know the numbers were reliable?
This chapter explores these options and how to implement them.
Note:The tasks in this chapter assume that you are already logged in to the Application Configuration Console Client.
Provisioning is pushing out assets and their configurations from Application Configuration Console to the targeted resources that constitute your business infrastructure. The implication is that once having loaded your assets into Application Configuration Console, you committed to managing your assets within, and consider any changes made outside the bounds of the application to be unwarranted and thus to be overwritten.
In Chapter 5, a comparison of
config.xml to its external resource detected a difference. Since, for the purposes of this discussion, the Application Configuration Console version is considered to be correct, we are going to provision this version.
There are a variety of ways to initiate a provisioning operation. The process that follows demonstrates one way:
In the Navigator view, expand Portal Lifecycle View > Development > App Server.
Right-click Server1 and select Synchronize > Synchronize View from the popup menu.
In the Synchronize Options dialog that opens, accept the default selection (Show outgoing changes) and click OK.
The Synchronize view that opens tells us that a single configuration (config.xml) in the Server1 asset differs from its external resource.
Right-click the asset (Server1) and select Provision from the popup menu. The Provision dialog opens. A few comments about the dialog:
Tag and Comment are optional. We filled in a comment but no tag.
We want to run now as opposed to a later time.
Since we did not select Include All Configurations, only the changed configuration will be provisioned.
Click OK to execute the provision operation. After a moment, a message denotes success (or failure) of the operation.
Note the following additional points about provisioning:
When you do a Synchronize view, the resource spec is re-evaluated to pick up any changes to files added or deleted.
You also can provision from the context (right-click) menu in the Navigator view. It opens the same provision dialog.
Application Configuration Console has built-in protection in the event the external resource has changed since the initial load or the last update (Stop on Conflict). This allows you to investigate the difference and make an informed decision about allowing the provision to proceed.
You can schedule a provision to occur at a later time, either as a one-time occurrence, or on a recurring basis.
Application Configuration Console supports a form of secure provisioning that works with sudo and PowerBroker environments to provide access control and audit trail functions.
When you provision a master asset, you have the option of provisioning some or all of the associated subordinate assets at the same time (the Provision dialog changes to accommodate this option).
Updating is pulling assets and configurations into Application Configuration Console from external resources. This is what you do initially to create assets, so when you perform an update, you overwrite the Application Configuration Console data with the current external resource. The implication is that you use Application Configuration Console to monitor activity, but institute change outside the application.
An earlier comparison between assets in Application Configuration Console detected a difference in the timeout property value between httpd1.conf files. Since we're unsure which is correct, we decide to pull in the value from the external resource.
In the Navigator view, expand Portal Lifecycle View > Development > Web Server.
Right-click Aeneas and select Synchronize > Update from the popup menu. The Update dialog opens.
The dialog is fairly simple. Tag and Comment are optional. You can expand the selected Container to choose individual configurations, if desired (we're going to leave it as is). Click OK to execute the Update operation.
After a moment, a message denotes success (or failure) of the operation:
Note that a configuration was skipped. We updated at the asset level, and only one of the two configurations in Application Configuration Console was different from its external resource.
Note the following additional points about updating:
When you update an asset, the resource specification is re-evaluated to pick up any changes and to identify new or deleted external files.
If you perform an update operation on a subordinate asset, the configuration information updated from the external resource will be overwritten the next time the subordinate is refreshed from its master.
A version is a snapshot in time of an asset and its configurations. Events such as provisions, updates, and tracking cause versions to be saved automatically. Saved versions include both Application Configuration Console data and external resources. Versions provide an audit trail and a recovery mechanism.
For a simple case, let's consider the configuration we just updated (
In the Navigator view, expand Portal Lifecycle View > Development > Web Server > Aeneas > Resource View.
Right-click httpd1.conf and select Open from the popup menu.
In the Editor area, click the Versions tab at the bottom to see all versions of this configuration since initial load, as shown in Figure 6-1:
As you can see, there currently are three versions of this configuration:
As it was when first loaded into Application Configuration Console
As it was immediately prior to the update
As it is now, based on the current content of the external resource
This graphic shows the commands available from the context (right-click) menu. If you multiselect versions, the context menu changes to offer the five compare operations shown here in the top portion.
Clearly, maintaining an audit history such as this gives you considerable recovery and reconciliation options in maintaining the integrity of your assets.
Note the following additional points about versioning:
When you view the versions of an asset, you see all versions of all configurations under that asset.
While versions are created automatically based on events such as provisions, updates, and so forth, you can save a version of an asset or configuration on demand, from the Navigator view.