Additional Steps for 5.8.x¶
Upgrade OpenNebula to the latest version¶
Upgrade your environment using the guide that better adapts to your setup from the ones listed here. Once your environment is upgraded, please follow the sections below.
Update ServerAdmin password to SHA256¶
Since 5.10 passwords and tokens are generated using SHA256. OpenNebula will update the DB automatically for your regular users (including oneadmin). However, you need to do the update for serveradmin manually. You can do so, with:
$ oneuser passwd --sha256 serveradmin `cat /var/lib/one/.one/sunstone_auth|cut -f2 -d':'`
Update your Hooks¶
Hooks are no longer defined in
oned.conf. You need to recreate any hook you are using in the OpenNebula database. Specific upgrade actions for each hook type are described below.
HA Hooks keep working as they did in previous versions. For design reasons, these are the only hooks which need to be defined in
oned.conf and cannot be managed via the API or CLI. You should preserve your previous configuration in
Fault Tolerance Hooks¶
In order to migrate fault tolerance hooks, just follow the steps defined in Fault Tolerance guide.
The vCenter Hooks, used for creating virtual networks, will be created automatically when needed.
Custom Hooks migration strongly depends on your use case for the hook. Below there is a list of examples which represent the most common use cases.
- Create/Remove hooks. Corresponds to the legacy
These hooks are now triggered by an API hook on the corresponding create/delete API call. For example, the following hook sends an email to the user when her user account is created:
USER_HOOK = [ name = "mail", on = "CREATE", command = "email2user.rb", arguments = "$ID $TEMPLATE"]
Now, in OpenNebula 5.12, you need to create the following hook template:
NAME = "mail", TYPE = API CALL = "one.user.allocate", COMMAND = "email2user.rb", ARGUMENTS = "$TEMPLATE"
and define the hook with
onehook create command.
To emulate the
ON=CREATE hook for VMs an API hook can be defined for
In general, any create/remove hook can be migrated using the following template:
NAME = hook-create-resource TYPE = api COMMAND = "<same-script-path>" ARGUMENTS = "<same-arguments>" CALL = "one.<resource>.allocate"
More information on defining API Hooks can be found here.
- State hooks
If there is a hook defined for a Host or VM state change, the hook template has to be inferred from the Hook definition in the 5.8
oned.conf file; see the example below:
# Legacy hook definition in oned.conf VM_HOOK = [ name = "advanced_hook", on = "CUSTOM", state = "ACTIVE", lcm_state = "BOOT_UNKNOWN", command = "log.rb", arguments = "$ID $PREV_STATE $PREV_LCM_STATE" ] # Hook template file NAME = advanced_hook TYPE = state COMMAND = "log.rb" ARGUMENTS = "$TEMPLATE" RESOURCE = VM ON = CUSTOM STATE = ACTIVE LCM_STATE = BOOT_UNKNOWN
Note that you may need to adapt the arguments of your hook, as
$ID is not currently supported. More information on defining state Hooks can be found here.
Note that, in both examples,
ARGUMENTS_STDIN=yes can be used for passing the parameters via STDIN instead of command line argument.