wls migratable target

Overview

This resource allows you to managed migratable targets in a WebLogic domain.

Here is an example on how you should use this:

wls_migratable_target { 'wlsServer1 (migratable)':
  ensure                     => 'present',
  cluster                    => 'WebCluster',
  migration_policy           => 'manual',
  number_of_restart_attempts => '6',
  seconds_between_restarts   => '30',
  user_preferred_server      => 'wlsServer1',
}

In this example you are managing a migratable target in the default domain. When you want to manage a migratable target in a specific domain, you can use:

wls_migratable_target { 'my_domain/wlsServer2 (migratable)':
  ensure                     => 'present',
  cluster                    => 'WebCluster',
  migration_policy           => 'manual',
  number_of_restart_attempts => '6',
  seconds_between_restarts   => '30',
  user_preferred_server      => 'wlsServer2',
}

Here are some more examples:

wls_migratable_target { 'Wls11gSetting/wlsServer1 (migratable)':
  ensure                     => 'present',
  cluster                    => 'WebCluster',
  migration_policy           => 'manual',
  number_of_restart_attempts => '6',
  seconds_between_restarts   => '30',
  user_preferred_server      => 'wlsServer1',
}
wls_migratable_target { 'Wls11gSetting/wlsServer2 (migratable)':
  ensure                     => 'present',
  cluster                    => 'WebCluster',
  migration_policy           => 'manual',
  number_of_restart_attempts => '6',
  seconds_between_restarts   => '30',
  user_preferred_server      => 'wlsServer2',
}

Attributes

additional_migration_attempts

A migratable service could fail to come up on every possible configured server. This attribute controls how many further attempts, after the service has failed on every server at least once, should be tried. Note that each attempt specified here indicates another full circuit of migrations amongst all the configured servers. So for a 3-server cluster, and a value of 2, a total of 4 additional migrations will be attempted. (the original server is never a valid destination)

An example on how to use this:

wls_migratable_target {a_wls_migratable_target :
   ...
   additional_migration_attempts => '2'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_migratable_target:additional_migration_attempts']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_migratable_target

cluster

The cluster this migratable tragte should be targetted to

Back to overview of wls_migratable_target

constrained_candidate_servers

The list of servers this migratable target should be constrained to

Back to overview of wls_migratable_target

critical

Returns true if the MigratableTarget is critical to the overall health of the WLS Server

An example on how to use this:

wls_migratable_target {a_wls_migratable_target :
   ...
   critical => 1,
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_migratable_target:critical']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_migratable_target

disable_autorequire

Puppet supports automatic ordering of resources by autorequire. Sometimes, however, this causes issues. Setting this parameter to true, disables autorequiring for this specific resource.

USE WITH CAUTION!!

Here is an example on hopw to use this:

...{'domain_name/...':
  disableautorequire => true,
  ...
}

Back to overview of wls_migratable_target

disable_corrective_change

Disable the modification of a resource when Puppet decides it is a corrective change.

(requires easy_type V2.11.0 or higher)

When using a Puppet Server, Puppet knows about adaptive and corrective changes. A corrective change is when Puppet notices that the resource has changed, but the catalog has not changed. This can occur for example, when a user, by accident or willingly, changed something on the system that Puppet is managing. The normal Puppet process then repairs this and puts the resource back in the state as defined in the catalog. This process is precisely what you want most of the time, but not always. This can sometimes also occur when a hardware or network error occurs. Then Puppet cannot correctly determine the current state of the system and thinks the resource is changed, while in fact, it is not. Letting Puppet recreate remove or change the resource in these cases, is NOT wat you want.

Using the disable_corrective_change parameter, you can disable corrective changes on the current resource.

Here is an example of this:

crucial_resource {'be_carefull':
  ...
  disable_corrective_change => true,
  ...
}

When a corrective ensure does happen on the resource Puppet will not modify the resource and signal an error:

    Error: Corrective change present requested by catalog, but disabled by parameter disable_corrective_change
    Error: /Stage[main]/Main/Crucial_resource[be_carefull]/parameter: change from '10' to '20' failed: Corrective change present requested by catalog, but disabled by parameter disable_corrective_change. (corrective)

Back to overview of wls_migratable_target

disable_corrective_ensure

Disable the creation or removal of a resource when Puppet decides is a corrective change.

(requires easy_type V2.11.0 or higher)

When using a Puppet Server, Puppet knows about adaptive and corrective changes. A corrective change is when Puppet notices that the resource has changed, but the catalog has not changed. This can occur for example, when a user, by accident or willingly, changed something on the system that Puppet is managing. The normal Puppet process then repairs this and puts the resource back in the state as defined in the catalog. This process is precisely what you want most of the time, but not always. This can sometimes also occur when a hardware or network error occurs. Then Puppet cannot correctly determine the current state of the system and thinks the resource is changed, while in fact, it is not. Letting Puppet recreate remove or change the resource in these cases, is NOT wat you want.

Using the disable_corrective_ensure parameter, you can disable corrective ensure present or ensure absent actions on the current resource.

Here is an example of this:

crucial_resource {'be_carefull':
  ensure                    => 'present',
  ...
  disable_corrective_ensure => true,
  ...
}

When a corrective ensure does happen on the resource Puppet will not create or remove the resource and signal an error:

    Error: Corrective ensure present requested by catalog, but disabled by parameter disable_corrective_ensure.
    Error: /Stage[main]/Main/Crucial_resource[be_carefull]/ensure: change from 'absent' to 'present' failed: Corrective ensure present requested by catalog, but disabled by parameter disable_corrective_ensure. (corrective)

Back to overview of wls_migratable_target

domain

With this parameter, you identify the domain, where your objects is in.

The domain name is part of the full qualified name of any WebLogic object on a system. Let’s say we want to describe a WebLogic server. The full qualified name is:

wls_server{'domain_name/server_name':
  ensure => present,
  ...
}

When you don’t specify a domain name, Puppet will use default as domain name. For every domain you want to manage, you’ll have to put a wls_settings in your manifest.

Back to overview of wls_migratable_target

ensure

The basic property that the resource should be in.

Valid values are present, absent.

Back to overview of wls_migratable_target

hosting_server

Returns the name of the server that currently hosts the singleton service.

An example on how to use this:

wls_migratable_target {a_wls_migratable_target :
   ...
   hosting_server => 'a_value'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_migratable_target:hosting_server']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_migratable_target

migratable_target_name

The name of this migratable target

Back to overview of wls_migratable_target

migration_policy

The migration policy for migratable target

Valid values are absent, manual, exactly-once, failure-recovery.

Back to overview of wls_migratable_target

millis_to_sleep_between_attempts

Controls how long of a pause there should be between the migration attempts described in getAdditionalMigrationAttempts(). Note that this delay only happens when the service has failed to come up on every server. It does not cause any sort of delay between attempts to migrate otherwise.

An example on how to use this:

wls_migratable_target {a_wls_migratable_target :
   ...
   millis_to_sleep_between_attempts => '300000'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_migratable_target:millis_to_sleep_between_attempts']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_migratable_target

name

The name.

Back to overview of wls_migratable_target

non_local_post_allowed

Specifies whether or not the post-deactivation script is allowed to run on a different machine. Normally, when auto migration occurs, the post-deactivation script will be run on the service’s current location, and the pre-activation script on the service’s new location. If the current location is unreachable for some reason, this value will be checked to see if it is safe to run it on the service’s new machine. This is useful if the post-deactivation script controls access to a networked resource and does not need any data from the current machine.

An example on how to use this:

wls_migratable_target {a_wls_migratable_target :
   ...
   non_local_post_allowed => 1,
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_migratable_target:non_local_post_allowed']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_migratable_target

notes

Optional information that you can include to describe this configuration. WebLogic Server saves this note in the domain’s configuration file (config.xml) as XML PCDATA. All left angle brackets (<) are converted to the XML entity <. Carriage returns/line feeds are preserved. Note: If you create or edit a note from the Administration Console, the Administration Console does not preserve carriage returns/line feeds.

An example on how to use this:

wls_migratable_target {a_wls_migratable_target :
   ...
   notes => 'a_value'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_migratable_target:notes']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_migratable_target

number_of_restart_attempts

number_of_restart_attempts

Back to overview of wls_migratable_target

post_script

Specifies the path to the post-migration script to run after a migratable target is fully deactivated. The script must be in the MIDDLEWARE_HOME/user_projects/domains/mydomain/bin/service_migration directory. After the migratable target is deactivated, if there is a script specified, and Node Manager is available, then the script will run. Specifying a script without an available Node Manager will result in an error upon migration.

An example on how to use this:

wls_migratable_target {a_wls_migratable_target :
   ...
   post_script => 'a_value'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_migratable_target:post_script']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_migratable_target

post_script_failure_fatal

Specifies whether or not a failure during execution of the post-deactivation script is fatal to the migration. If it is fatal, the migratable target will not be automatically migrated until an administrator manually migrates it to a server, thus reactivating it. Note: Enabling this value will result in weakening the exactly-once guarantee. It is provided to prevent more dangerous data corruption if the post-deactivation script fails. Also if this value is enabled, then the script may be called more than once by the migration framework after the Migratable Target is deactivated or the server or machine hosting the Migratable Target crashed or is network partitioned. The script is expected not to return different exit values when invoked multiple times in such scenarios.

An example on how to use this:

wls_migratable_target {a_wls_migratable_target :
   ...
   post_script_failure_fatal => 1,
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_migratable_target:post_script_failure_fatal']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_migratable_target

pre_script

Specifies the path to the pre-migration script to run before a migratable target is actually activated. The script must be in the MIDDLEWARE_HOME/user_projects/domains/mydomain/bin/service_migration directory. Before the migratable target is activated, if there is a script specified, and Node Manager is available, then the script will run. Specifying a script without an available Node Manager will result in an error upon migration. If the script fails or cannot be found, migration will not proceed on the current server, and will be tried on the next suitable server. This could be the next server in the candidate server list, or in the cluster, if there is no candidate server list.

An example on how to use this:

wls_migratable_target {a_wls_migratable_target :
   ...
   pre_script => 'a_value'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_migratable_target:pre_script']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_migratable_target

provider

The specific backend to use for this wls_migratable_target resource. You will seldom need to specify this — Puppet will usually discover the appropriate provider for your platform.Available providers are:

simple

Manage a migratable target of a WebLogic domain via regular WLST

Back to overview of wls_migratable_target

restart_on_failure

Specifies whether or not a failed service will first be deactivated and reactivated in place, instead of being migrated. The number of restart attempts is controlled by {@link #getNumberOfRestartAttempts}. Once these restart attempts are exhausted, the service will migrate. A restarting migratable target will deactivate all services on it in order, then reactivate them all.

An example on how to use this:

wls_migratable_target {a_wls_migratable_target :
   ...
   restart_on_failure => 1,
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_migratable_target:restart_on_failure']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_migratable_target

seconds_between_restarts

The amount of milliseconds to wait between attempts to migrate this migratable target

Back to overview of wls_migratable_target

tags

Return all tags on this Configuration MBean

An example on how to use this:

wls_migratable_target {a_wls_migratable_target :
   ...
   tags => 'a_value'
   ...
}

This is an extended property. Before you can use it add it to the wls_settings property extra_properties.

wls_setting{'domain':
   ...
  extra_properties => ['wls_migratable_target:tags']
   ...
}

This help text generated from MBean text of the WebLogic server.

Back to overview of wls_migratable_target

user_preferred_server

The preferred server to run this migratable target on

Back to overview of wls_migratable_target