Terraform Import and PowerFlex SDC Volumes Mapping
Wed, 07 Aug 2024 13:47:10 -0000
|Read Time: 0 minutes
Terraform execution model
Terraform is a powerful infrastructure-as-code tool for provisioning and deprovisioning use cases. A single Terraform configuration can constitute multiple infrastructure components defined as resources across multiple .tf files. Terraform resources are the objects that make up the state of a particular Terraform configuration. When we run the terraform apply command, Terraform attempts to make changes to the infrastructure to match the declared configuration. A unique aspect of Terraform configuration is that there is no explicit directive to create or delete resources. Terraform implicitly determines whether to create or delete resources or do nothing based on the actual state of the infrastructure and the declared configuration. This is why you run the terraform plan command to see a summary of all the resources being created and destroyed before applying the configuration. In this blog post, using the PowerFlex SDC_Volume_Mappings resource example, I will present the role of the import functionality of Terraform in capturing the existing state of infrastructure and avoiding unintended changes to the infrastructure.
Handling pre-existing resources
Let us consider a Terraform resource that may have already existed in the infrastructure before we began using Terraform to manage it. In order to manage such resources, we must first do an import of the resource so that the current state of the resource is captured in the Terraform state. If we don’t do this, we will end up with a state that conflicts with reality, which then forces Terraform to update the state of the resource strictly to the one declared in the configuration, thus undoing the pre-existing resource state.
SDC Volume Mappings example
A great example of this is the SDC_Volume_Mappings resource in Dell PowerFlex. Let’s say you are provisioning a new volume to a host and creating the SDC mapping between them using the SDC_Volumes_Mapping resource corresponding to the host. It is very likely that the host may already be mapped to many volumes and Terraform doesn’t know about that—in some cases, you may not have checked it either. In such a situation, you may accidentally—unless you catch this by meticulously going through the terraform plan output—unmap volumes that are already mapped to the host SDC. We definitely don’t want to inadvertently unmount volumes from hosts, so how do we do this properly? Here is where terraform import comes into picture.
Following is the configuration to create a volume and map it to a host:
resource "powerflex_volume" "pfx_volume" { name = var.pfx_vol_esxi size = 8 storage_pool_name = var.pfx_sp protection_domain_name= var.pfx_pd access_mode = "ReadWrite" } resource "powerflex_sdc_volumes_mapping" "esxi_mapping" { id = data.powerflex_sdc.esxi_mapped.sdcs[0].id volume_list = [{ volume_id = powerflex_volume.pfx_volume.id access_mode = "ReadWrite" }] }
Note that the volume_list for the ESXi host contains only the newly created volume. That said, this ESXi host already has a volume mapped to it:
The following shows a terraform apply with configuration results in the following state where only the new volume is shown under mapped volumes for the host and not the existing ansible-volume-demo:
However, in the next terraform plan step, Terraform sees the conflict between its state of the resource and the actual resource and therefore tries to force the state by unmapping the existing Ansible volume:
To avoid this situation, we first need to import the resource with the following command:
terraform import "powerflex_sdc_volumes_mapping.esxi_mapping" <sdc-id>
After the import step, the Terraform state for the SDC_Volumes_Mapping resource in our example looks like the following:
Now, to reflect this existing state, we must update our SDC_Volumes_Mapping resource configuration to include the existing volume. To do this, copy-paste the volume list items that are missing from the configuration as follows:
Note that I commented out volume_name since only one of volume_id and volume_name is allowed in the resource.
Finally, the Terraform plan actually reflects this updated state:
And that’s it! Now you know how to use import for a resource like SDC_Volumes_Mapping in Dell PowerFlex and update your Terraform configuration to reflect the actual state of the resource even before Terraform starts to manage it.
Terraform resources
Here are the link sets for key resources for each of the Dell Terraform providers:
Provider for PowerScale
Provider for PowerFlex
Provider for PowerStore
Provider for Redfish
Provider for APEX Navigator
Author: Parasar Kodati, Engineering Technologist, Dell ISG