Q2 2023 Release for Ansible Integrations with Dell Infrastructure
Thu, 29 Jun 2023 11:21:49 -0000
|Read Time: 0 minutes
Thanks to the quarterly release cadence of infrastructure as code integrations for Dell infrastructure, we have a great set of enhancements and improved functionality as part of the Q2 release. The Q2 release is all about data protection and data security. Data services that come with the ISG storage portfolio deliver huge value in terms of built-in data protection, security, and recovery mechanisms. This blog provides a summary of what’s new in the Ansible collections for Dell infrastructure:
Ansible Modules for PowerStore v2.0.0
- A new module to manage Storage Containers. More in the subsection below.
- An easier way to get replication_session details. The replication_session module is updated to use a new replication_group parameter, which can take either the name or ID of the group to get replication session details.
Support for PowerStore Storage Containers
Storage Containers is a logical group of vVol on PowerStore. Learn more here. In v2.0 of Ansible Collections for PowerStore, we are introducing a new module to create and manage the Storage Containers from within Ansible. Let’s start with the list of parameters for the Storage Container task:
Parameter name | Type | Description |
storage_container_id | string | Unique identifier of the storage container. Mutually exclusive with storage_container_name |
storage_container_name | string | Name of the storage container. Mutually exclusive with storage_container_id. Mandatory for creating a storage container. |
new_name | string | The new name of the storage container |
quota | int | The total number of bytes that can be provisioned/reserved against this storage container. |
quota_unit | string | Unit of the quota |
storage_protocol | string | The type of Storage Container.
|
high_water_mark | int | This is the percentage of the quota that can be consumed before an alert is raised. |
force_delete | bool | This option overrides the error and allows the deletion to continue in case there are any vVols associated with the storage container. |
state | string | The state of the storage container after execution of the task. Choices: ['present', 'absent'] |
storage_container_destination_state | str | The state of the storage container destination after execution of the task. Required while deleting the storage container destination. Choices: [present, absent] |
storage_container_destination | dict | Dict container remote system and remote storage container. |
remote_system
remote_address
user
password
validate_certs
port
timeout
remote_storage_container | str | The name/id of the remote system |
str | The IP address of the remote array | |
str | Username for the remote array | |
str | Password for the remote array | |
bool | Whether or not to verify the SSL certificate | |
int | Port of the remote array (443) | |
int | Time after which the connection will get terminated (120) | |
str | The unique name/id of the destination storage container on the remote array |
Here are some YAML snippet examples to use the new module:
Task | Example |
Get a storage container | - name: Get details of a storage container Let me call this snippet <basic-sc-details> for reference
|
Create a new storage container | <basic-sc-details> quota: 10
|
Delete a storage container | <basic-sc-details> state: 'absent' |
Create a storage container destination | <basic-sc-details> storage_container_destination: "Destination_container" |
Ansible Modules for PowerFlex v1.7.0
- A new module to create and manage snapshot policies
- An enhanced replication_consistency_group module to orchestrate workflows, such as failover and failback, that are essential for disaster recovery.
- An enhanced SDC module to assign a performance profile and option to remove an SDC altogether.
Create and manage snapshot policies
If you want to refresh your knowledge here is a great resource to learn all about snapshots and snapshot policy setup on PowerFlex. In this version of Ansible collections for PowerFlex, we are introducing a new module for snapshot policy setup and management from within Ansible.
Here are the parameters for the snapshot policy task in Ansible:
Parameter name | Type | Description |
snapshot_policy_id | str | Unique identifier of the snapshot policy |
snapshot_policy_name | str | Name of the snapshot policy |
new_name | str | The new name of the snapshot policy |
access_mode | str | Defines the access for all snapshots created with this snapshot policy |
secure_snapshots | bool | Defines whether the snapshots created from this snapshot policy will be secure and not editable or removable before the retention period is complete |
auto_snapshot_creation_cadence
-- time -- unit | dict -- int -- str | The auto snapshot creation cadence of the snapshot policy. |
num_of_retained_snapshots_per_level | list | The number of snapshots per retention level. There are one to six levels, and the first level has the most frequent snapshots. |
source_volume
-- id
-- name
-- auto_snap_removal_action -- detach_locked_auto_snapshots -- state | list of dict -- str -- str
-- bool
-- str | The source volume details to be added or removed.
-- Whether to detach the locked auto snapshots during the removal of the source volume. -- State of the source volume: |
pause | bool | Whether to pause or resume the snapshot policy |
state | str | State of the snapshot policy after execution of the task |
And some examples of how the task can be configured in a playbook:
Get details of a snapshot policy | - name: Get snapshot policy details using name Let me call the above code block <basic-policy-details> for reference |
Create a policy | <basic-policy-details> |
Delete a policy | <basic-policy-details> state: "absent" |
Add source volumes to a policy | <basic-policy-details> source_volume: |
Remove source volumes from a policy | <basic-policy-details> source_volume: |
Pause/resume a snapshot policy | <basic-policy-details> pause: True //False to resume |
Failover and failback workflows for consistency groups
Today Ansible collections for PowerFlex already has the replication consistency group module to create and manage consistency groups, and to create snapshots of these consistency groups. Now we are also adding workflows that are essential for disaster recovery. Here is what the playbook tasks look like for various DR tasks:
Task | Syntax |
Code block: <Access details and name of consistency group> | gateway_host: "{{gateway_host}}" |
Failover the RCG | - name: Failover the RCG rcg_state: 'failover' |
Restore the RCG | - name: Restore the RCG |
Switch over the RCG | - name: Switch over the RCG rcg_state: 'switchover' |
Synchronization of the RCG | - name: Synchronization of the RCG rcg_state: 'sync' |
Reverse the direction of replication for the RCG | - name: Reverse the direction of replication for the RCG rcg_state: 'reverse' |
Force switch over the RCG | - name: Force switch over the RCG rcg_state: 'switchover' force: true |
Ansible Modules for PowerScale v2.0.0
This release for Ansible Collections for PowerScale has enhancements related to the theme of identity and access management which is fundamental to the security posture of a system. We are introducing a new module, user_mappings which corresponds to the user mappings feature of OneFS.
New module for user_mappings
Let’s see some examples of creating and managing user_mappings:
Common code block: <user-mapping-access> | dellemc.powerscale.user_mapping_rules: onefs_host: "{{onefs_host}}" verify_ssl: "{{verify_ssl}}" api_user: "{{api_user}}" api_password: "{{api_password}}" |
Get user mapping rules of a certain order | - name: Create a user mapping rule <user-mapping-access> Order: 1 |
Create a mapping rule | - name: Create a user mapping rule <user-mapping-access> operator: "insert" options: break_on_match: false group: true groups: true user: true user1: user: "test_user" user2: user: "ans_user" state: 'present' |
Delete a rule | <user-mapping-access> Order: 1 state: "absent" |
As part of this effort the Info module also has been updated to get all the user mapping rules and LDAPs configured with OneFS:
- name: Get list of user mapping rules <user-mapping-access> gather_subset: -user_mapping_rules - name: Get list of ldap of the PowerScale cluster <user-mapping-access> gather_subset: -ldap
Filesystem and NFS module enhancements
The Filesystem module continues the theme of access control and now allows you to pass a new value called ‘wellknown’ for the Trustee type when setting Access Control for the file system. This option provides access to all users. Here is an example:
- name: Create a Filesystem filesystem: onefs_host: "{{onefs_host}}" api_user: "{{api_user}}" api_password: "{{api_password}}" verify_ssl: "{{verify_ssl}}" path: "{{acl_test_fs}}" access_zone: "{{access_zone_acl}}" access_control_rights: access_rights: "{{access_rights_dir_gen_all}}" access_type: "{{access_type_allow}}" inherit_flags: "{{inherit_flags_object_inherit}}" trustee: name: 'everyone' type: "wellknown" access_control_rights_state: "{{access_control_rights_state_add}}" quota: container: True owner: name: '{{acl_local_user}}' provider_type: 'local' state: "present"
The NFS module now can handle the case of unresolvable hosts in terms of ignoring or erroring out with a new parameter called ignore_unresolvable_hosts that can be set to True (ignores) or False (errors out).
Ansible Modules for Dell Unity v1.7.0
V1.7 of Ansible collections for Dell Unity follow the theme of data protection as well. We are introducing a new module for data replication and recovery workflows that are key to disaster recovery. The new replication_session module allows you to manage data replication sessions between two Dell Unity storage arrays. You can also use the module to initiate DR workflows such as failover and failback. Let’s see some examples:
Common code block to access a replication session: <unity-replication-session> | dellemc.unity.replication_session: unispherehost: "{{unispherehost}}" username: "{{username}}" password: "{{password}}" validate_certs: "{{validate_certs}}" name: "{{session_name}}" |
Pause and resume a replication session | - name: Pause (or resume) a relication session <unity-replication session> Pause: True //(False to resume) |
Failover the source to target for a session | - name: Failover a replication session <unity-replication-session> failover_with_sync: True force: True |
Failback the current session (that is in a failover state) to go back to the original source and target replication sessions | - name: Failback to original replication session <unity-replication-session> failback: True force_full_copy: True |
Sync the target with the source | - name: Sync a replication session <unity-replication-session> failover_with_sync: True sync: True |
Delete or suspend a replication session | - name: Failover a replication session <unity-replication-session> state: “absent” |
Ansible Modules for PowerEdge (iDRAC and OME)
When it comes to PowerEdge servers, the openmanage Ansible collection is updated every month! In my Q1 release blog post, I covered till v7.3. If you noticed, we started talking about Roles! To make the iDRAC tasks easy to manage and execute, we started grouping iDRAC tasks into appropriate Ansible Roles. Since v7.3, three (number of months in a quarter!) more releases happened, each one adding new Roles to the mix. For a roll up of features in the last three months, here are the details:
New roles in v7.4, v7.5, and v7.6:
- dellemc.openmanage.idrac_certificate - Role to manage the iDRAC certificates - generate CSR, import/export certificates, and reset configuration - for PowerEdge servers.
- dellemc.openmanage.idrac_gather_facts - Role to gather facts from the iDRAC Server.
- dellemc.openmanage.idrac_import_server_config_profile - Role to import iDRAC Server Configuration Profile (SCP).
- dellemc.openmanage.idrac_os_deployment - Role to deploy the specified operating system and version on the servers.
- dellemc.openmanage.idrac_server_powerstate - Role to manage the different power states of the specified device.
- dellemc.openmanage.idrac_firmware - Firmware update from a repository on a network share (CIFS, NFS, HTTP, HTTPS, FTP).
- dellemc.openmanage.redfish_firmware - Update a component firmware using the image file available on the local or remote system.
- dellemc.openmanage.redfish_storage_volume - Role to manage the storage volume configuration.
- dellemc.openmanage.idrac_attributes - Role to configure iDRAC attributes.
- dellemc.openmanage.idrac_bios - Role to modify BIOS attributes, clear pending BIOS attributes, and reset the BIOS to default settings.
- dellemc.openmanage.idrac_reset - Role to reset and restart iDRAC (iDRAC8 and iDRAC9 only) for Dell PowerEdge servers.
- dellemc.openmanage.idrac_storage_controller - Role to configure the physical disk, virtual disk, and storage controller settings on iDRAC9 based PowerEdge servers.
OME module enhancements
- Plugin OME inventory enhanced to support the environment variables for the input parameters.
- ome_template module enhanced to include job tracking.
Other enhancements
- redfish_firmware module is enhanced to include job tracking.
- Updated the idrac_gather_facts role to use jinja template filters.
Author: Parasar Kodati