Update Dell PowerProtect Datamanager Appliance using Ansible and REST API
Disclaimer: use this at your own Risk
why that ?
Automation is everywhere. Automation should your standards. Automation should be based on (Rest) API´s.
As our customers broadly use Ansible to automate standard IT Tasks, i created this Example use case to manage Dell PowerProtect Datamanager´s Update lifecycle.
My Friend Preston De Guise has written a nice Blogpost on PowerProtect Data Manager 19.11 – What’s New, and Updating
We will do all of his outlined steps to update a PowerProtect Datamanager from 19.10 to 19.11 using Ansible.
The individual API Calls are Organized in Ansible roles and will be executed from corresponding Playbooks
what we need
In general, all of the following playbooks / roles are built with the Ansible URI module ( with one exception :-) )
They have been tested from Ubuntu Linux ( running from WSL2 ), best “Ubuntu 20.04.4 LTS” for python 3.8 support
i am happy to share my ansible roles per request for now.
so let us walk trough a typical update scenario
1. Uploading the Update Package
1.1 the get_ppdm_token role to authenticate with the api endpoint
All of the playbooks require to authenticate via the API endpoint and use a Bearer token for Subsequent requests.
so i use a role called get_ppdm_token to retrieve the token from the API:
1.2 the upload_update role for uploading a package to PPDM
to upload an update package, we have to use a curl via an ansible shell call ( this being the one exception :-) ), as an upload vi URI Module fails for files > 2GB
1.3 Playbook to upload the Update Package
The following snippet is an example of an Upload Playbook
The Playbook will run like this:
2. Pre Checking the Update
The Update Pre Check will inform you about Required Actions need to be taken in order to make the update succeed.
It will also show us Warnings for issues we might correct prior the Update.
2.1 the get_ppdm_update_package role for getting the Update ID
PPDM has an API endpoint to get all Updates in the System. This could be active or historical Updates.
The Response Contains JSON Documents with specific information and state about the Update
This task allows us to get info a specific update by using the update ID, or filter an update by type ( e.g. ACTIVE or HISTORY )
2.2 example Playbook to get an ACTIVE Update Content
This example shows the JSON response for the Update Package with Essential information for example Versions,Required Passwords/Reboot, Updated EULA´s, ID etc:
2.3 the precheck_ppdm_update_package role
After reviewing the Information, we will trigger the Pre Check using the precheck endpoint.
This will transform the Package state to Processing.
The below Precheck role will wait for the state AVAILABLE and the Validation Results:
2.4 Running the Precheck Playbook
The Corresponding Playbook for above task will may look like this:
The Playbook will output the validation Details:
3. Executing the Upgrade
Once the Update Validation has passed, we can execute the Update
3.1 the install_ppdm_update_package role
The below example task shows the upgrade-packages endpoint to be called
A JSON Body needs to be provided with additional information.
We wil create the Body from the Calling Playbook
3.2 the check_update_done role
Once the Update is started, PPDM sysmgr and other components will shut down.
PPDM has a specific API Port to Monitor the Update( also from the UI, Port 14443)
The check_update_done role will wait until the Update reaches 100%
3.3 Playbook to install the Update
to install the update, we will modify the update-package JSON document to change the state field to INSTALLED.
Also, we will approve updated EULA Settings and trust the Package Certificate.
The changes will be merged from the Playbook.
The corresponding Playbook looks like
We can follow the Upgrade Process from the Ansible Playbook:
And also use the Webbrowser at “https://:14443" to see the Update Status: