Before Upgrade¶

Install python-crypto¶

This python module is not strictly necessary, as the agent ships a pure-python AES implementation, but the cpu usage is noticeably lower with this module installed.

If python-crypto is available as a system package, use the system's command. For example:

# debian, ubuntu
$ sudo apt install python-crypto

# SuSE
$ sudo zypper in python-pycrypto

Else:

$ sudo pip install python-crypto

Stop docker services¶

The private docker daemon socket changes location. So the daemon needs stopping before upgrade and starting after upgrade. Only services with docker_daemon_private = true (the default) need this precaution.

Freeze all services¶

sudo svcmgr freeze

Unconfigure OpenHA¶

sudo /etc/init.d/openha kill

Then, backup configuration files and disable the launcher or remove the package.

Set node.maintenance_grace_period¶

A node now announces its entering 'maintenance' upon clean daemon stop and restart. A node reboot is a clean stop too. Peer nodes won't try to take over the services which were running on this node until node.maintenance_grace_period is expired, so the services have a chance to be restarted on the same node after the maintenance is over.

Note

node.maintenance_grace_period default value is 60 seconds

Set node.rejoin_grace_period¶

Note

node.rejoin_grace_period default value is 90 seconds

Unset DEFAULT.mode¶

This service keyword is unused since 1.8.

Set DEFAULT.orchestrate¶

This parameter is used to restrict or allow the daemon orchestration capabilities for the service.

If not set explicitely, the orchestrate value defaults to no, disabling all start orchestration.

The other valid values, start and ha, require that you also set and configure the service placement policy. The default placement, nodes order, ranks the nodes respecting the user-defined order of the nodes and :kw:drpnodes keywords.

Users can change the orchestrate value online at any moment. For example activating ha on a service can be done with sudo svcmgr -s svc1 set --kw orchestrate=ha

Any 1.8 service with no hearbeat resource (manual failover) can behave like a HA service as soon as the agent stack is upgraded to 1.9

Conversion table:

Service Type	v1.8	v1.9	Comments
failover no hb	[DEFAULT] nodes = n1 n2 autostart_node =	[DEFAULT] nodes = n1 n2 orchestrate = no	orchestrate=no keeps the daemon from starting the instance on any node, and inhibits failover. The nodes order is only important to determine the node where the shared resources are provisioned.
failover no hb	[DEFAULT] nodes = n1 n2 autostart_node = n2	[DEFAULT] nodes = n2 n1 orchestrate = start	orchestrate=start let the daemon start the instance on the placement leader only, but inhibits failover. n2 is defined as first node, so the placement policy selects it as the leader
failover with hb	[DEFAULT] nodes = n1 n2 autostart_node =	[DEFAULT] nodes = n2 n1 orchestrate = ha	orchestrate=ha let the daemon start the instance and handle failover. The nodes order must be set in the same order defined in the openha 'services' configuration file.
flex	[DEFAULT] nodes = n1 n2 n3 autostart_node = n2 n3	[DEFAULT] nodes=n2 n3 n1 flex_min_nodes=2 orchestrate = start	orchestrate=start let the daemon start instances on the 2 (flex_min_nodes) first placement leaders. n2 and n3 are defined first, so the placement policy selects them as the leaders.
flex	[DEFAULT] nodes = n1 n2 n3 autostart_node =	[DEFAULT] nodes=n1 n2 n3 orchestrate = no	orchestrate=no keeps the daemon from starting instances on any nodes, and inhibits restart of dead instances to satisfy flex_min_nodes. The nodes order is only important to determine the node where the shared resources are provisioned.

Set DEFAULT.placement¶

This parameter is used to set a service instances placement policy. It is used to identify which node is the most appropriate to start the service.

Possible values:

nodes order : the left-most available node is allowed to start a service instance
load avg : the least loaded node, taken from system load averages in the past 15 minutes
spread : a static random spread

Note

DEFAULT.placement default value is nodes order

Set DEFAULT.constraints¶

An expression evaluating as a boolean, constraining the service instance placement to nodes where constraints evaluates as True.

Supported syntax:

comparison operators are == != > >= <= in (e1 e2) in [e1 e2]
arithmetic operators are * + - / ** // %
binary operators are & | ^
negation operator is not
boolean operators are and or
references are allowed
Strings, and references evaluating as strings, containing dots must be quoted

Examples:

constraints = $("{nodename}"=="node2.acme.com")
constraints = $("{nodename}"=="node1" or "{node.env}" in (DEV, TST))

Note

The constraints are not honored by manual start operations.
The constraints violation notification is added to "print status" and "json status" outputs

Rename DEFAULT.affinity to DEFAULT.hard_affinity¶

for SVCNAME in $(sudo svcmgr ls)
do
        BUFF=$(sudo svcmgr -s $SVCNAME get --param affinity) && ( \
                sudo svcmgr -s $SVCNAME set --param hard_affinity --value "$BUFF" ; \
                sudo svcmgr -s $SVCNAME unset --param affinity \
        )
done

Rename DEFAULT.anti_affinity` to DEFAULT.hard_anti_affinity¶

for SVCNAME in $(sudo svcmgr ls)
do
        BUFF=$(sudo svcmgr -s $SVCNAME get --param anti_affinity) && ( \
                sudo svcmgr -s $SVCNAME set --param hard_anti_affinity --value "$BUFF" ; \
                sudo svcmgr -s $SVCNAME unset --param anti_affinity \
        )
done

Remove DEFAULT.autostart_node¶

Previously used for primary node definition at service startup, this parameter is now obsolete. This feature is now managed by the service placement policy and orchestrate. The placement policy algorithm is responsible of primary node identification, so make sure the placement policy produce the same behaviour.

When using nodes order (default) placement policy, the service will start on the first node declared in the DEFAULT.nodes parameter.

Examples:

nodes = n1 n2 n3

n1 is the primary node, n2 and n3 are secondary nodes.

nodes = n3 n2 n1

n3 is the primary node, n2 and n1 are secondary nodes.

Remove hb sections from service configurations¶

heartbeats resources are now deprecated, and should be removed from the service configuration file.

To remove rid hb#1 resource from service svc1:

sudo svcmgr -s svc1 delete --rid hb#1

Remove the rid from the service configuration file.

sudo svcmgr -s svc1 sync drp --rid sync#i0

Propagate the updated service configuration file to drp node, if any.

Replace optional_on, monitor_on, enable_on and disable_on by their equivalent scoped optional, monitor, enable and disable¶

v1.8	v1.9
<kw>_on = nodes	<kw>@nodes = true
<kw>_on = drpnodes	<kw>@drpnodes = true
<kw>_on = nodes drpnodes	<kw> = true

Replace sync[rsync].exclude by their equivalent sync[rsync].options¶

v1.8	v1.9
exclude = foo	options = --exclude=foo

Replace DEFAULT.service_env by their equivalent DEFAULT.env¶

for SVCNAME in $(sudo svcmgr ls)
do
        BUFF=$(sudo svcmgr -s $SVCNAME get --param svc_env) && ( \
                sudo svcmgr -s $SVCNAME set --param env --value "$BUFF" ; \
                sudo svcmgr -s $SVCNAME unset --param svc_env \
        )
done

Set <rid>.provision=false in your templates¶

For resources you don't want to provision using the opensvc provisioner. You can also set your own provisioner as a pre_provision trigger.

Set DEFAULT.parents and DEFAULT.children¶

If you implemented inter-services start or stop dependencies using triggers, you might now consider removing the triggers and use those keywords instead. Be aware the inter-dependent services must be hosted in the same cluster.

Set type=docker on docker ip resources¶

tags=docker is not longer sufficient to determine the resource should use the ip.docker driver. Set type=docker explicitely.

Verify disk.scsireserv monitor and optional values¶

The disk.scsireserv resources in 1.9 inherit their peer resource monitor and optional values. It was not the case in 1.8, so you might want want to force a value the disk#<n>pr.monitor and disk#<n>pr.optional to maintain the same behaviour after migration.

After Upgrade¶

Set <rid>.shared=true in your service configuration files and templates¶

On resources you want provisioned on one node only.

Configure the Clusters¶

verify the heartbeats and service status are up¶

sudo svcmon

Thaw services¶

sudo svcmgr -s '*' thaw

Replace always_on by standby¶

v1.8	v1.9
always_on = nodes	standby@nodes = true
always_on = drpnodes	standby@drpnodes = true
always_on = nodes drpnodes	standby = true

Rename DEFAULT.cluster_type to DEFAULT.topology¶

for SVCNAME in $(sudo svcmgr ls)
do
        BUFF=$(sudo svcmgr -s $SVCNAME get --param cluster_type) && ( \
                sudo svcmgr -s $SVCNAME set --param topology --value "$BUFF" ; \
                sudo svcmgr -s $SVCNAME unset --param cluster_type \
        )
done