ANSIBLE_LIBRARY=<path to Ansible4IOM>/modules/ \ ANSIBLE_ROLES_PATH=<path to Ansible4IOM>/roles/ \ ansible-playbook -i <path to inventory file>/inventory <path to Ansible4IOM>/processes/setup_oms_node.yml
The process consists of the following steps:
Execute post_oms_extract_hook.
IOM does not support an in-place update process, which transforms a host running an older version of IOM into one running a newer version. Instead, the installation has to be replaced completely. The complete replacement of the installation has the following things to ensure:
Since Process - Reconfigure OMS Node 1.0 can only reconfigure a limited set of configuration settings, process update_oms_node can be used to update other configurations than OMS_VERSION too.
Process - Reconfigure OMS Node gives an overview about configuration changes supported by different processes.
During the update process, the load balancer must not forward any requests to the IOM application servers. Since the load balancer uses health-check requests sent to the application servers to determine the application servers to use, the goal can be reached by marking all nodes as unhealthy. This is realized by stopping FTPd-service during update process.
Since the update process can run in parallel on different nodes, backend servers are not under control of the watchdog during this time. It has to be ensured, that the backend server must not execute jobs and must not receive and handle JMS messages.
Technically, this behavior is realized by roles oms_reconfig_for_attach_to_cluster and oms_reconfig_for_detach_from_cluster. When detached from the cluster, the backend server will not run any jobs and will not receive JMS messages. Even if it is running in parallel to other backend servers, the detached backend server will not influence the cluster at all.
Make sure your custom code and configuration are compatible to the new version of IOM to be installed. Just update the value of OMS_VERSION in your inventory file, e.g. from 2.2.0.0 to 2.2.1.0.
... [all:vars] # information required to access repo to download IOM package OMS_VERSION=2.2.1.0 ...
Now the process update_oms_node can be executed.
ANSIBLE_LIBRARY=<path to Ansible4IOM>/modules/ \ ANSIBLE_ROLES_PATH=<path to Ansible4IOM>/roles/ \ ansible-playbook -i <path to inventory file> <path to Ansible4IOM>/processes/update_oms_node.yml
According to Reference - Ansible4IOM Variables 1.0, a change of Wildflys admin user password is not supported by Process - Reconfigure OMS Node 1.0, but by the current update process. Since the variable JBOSS_ADMIN_PASSWD
, defined in roles/oms_config/defaults, is a hash, the variable cannot be set in the inventory file directly. The inventory file supports setting of simple variables only. To set complex variables, you have to use files located in the directory group_vars. Depending on the installation type you are using, you have to create a file within group_vars, which is named exactly as the server group assignment, you are using (oms_single_node, oms_ha_node, oms_azure_node).
The following example shows the settings that are necessary to update an Azure-Cloud installation of IOM. Frontend- and backend server will use different passwords.
JBOSS_ADMIN_PASSWD: { backend: "mySecretBackendPasswd", frontend: "mySecretFrontendPasswd" }
Now the process update_oms_node can be executed.
ANSIBLE_LIBRARY=<path to Ansible4IOM>/modules/ \ ANSIBLE_ROLES_PATH=<path to Ansible4IOM>/roles/ \ ansible-playbook -i <path to inventory file> <path to Ansible4IOM>/processes/setup_oms_node.yml
The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.