Use instance affinity policy on ibm_pi_volume
yussufsh opened this issue · 9 comments
In reference to IBM-Cloud/terraform-provider-ibm#2800 fix on the pi_volume resource, we need to use the instance affinity policy on the volume that are created by the automation.
With this option we don't need the volume_type aka diskType. This will prevent the errors we are getting recently on some regions due to storage pool placement. Also, there is no need of existing logic where a data source fetch the storage type from the image.
Note that this fix will be released in the next iteration of IBM provider plugin.
resource "ibm_pi_volume" "volume" {
count = var.storage_type == "nfs" ? 1 : 0
pi_volume_size = var.volume_size
pi_volume_name = "${var.name_prefix}-${var.storage_type}-volume"
pi_affinity_policy = "affinity"
pi_affinity_instance = ibm_pi_instance.bastion[count.index].pi_instance_name
pi_volume_shareable = var.volume_shareable
pi_cloud_instance_id = var.service_instance_id
}
resource "ibm_pi_instance" "bastion" {
count = local.bastion_count
pi_memory = var.bastion["memory"]
pi_processors = var.bastion["processors"]
pi_instance_name = "${var.name_prefix}-bastion-${count.index}"
pi_proc_type = var.processor_type
pi_image_id = local.bastion_image_id
pi_network_ids = [ibm_pi_network.public_network.network_id, data.ibm_pi_network.network.id]
pi_key_pair_name = ibm_pi_key.key.key_id
pi_sys_type = var.system_type
pi_cloud_instance_id = var.service_instance_id
pi_health_status = var.bastion_health_status
}
@yussufsh this looks okay? (using master branch ibmcloud-provider build)
@Prajyot-Parab I was using the latest provider version and found that storage_type is needed now for pi_instance. I am getting this error:
ibm_pi_instance.power_instance: Creating...
Error: failed to provision Failed to Create PVM Instance :[POST /pcloud/v1/cloud-instances/{cloud_instance_id}/pvm-instances][400] pcloudPvminstancesPostBadRequest &{Code:0 Description:bad request: calculated parameter has failed for cloud-instance 461efd70609341159d5fd6770747074b: storageType is required when not using a storage affinity policy Error:bad request Message:}
on main.tf line 22, in resource "ibm_pi_instance" "power_instance":
22: resource "ibm_pi_instance" "power_instance" {
So we still need to use storage type but in the pi_instance @ pi_storage_type and use the affinity for the pi_volume.
@Prajyot-Parab I was using the latest provider version and found that storage_type is needed now for pi_instance. I am getting this error:
ibm_pi_instance.power_instance: Creating... Error: failed to provision Failed to Create PVM Instance :[POST /pcloud/v1/cloud-instances/{cloud_instance_id}/pvm-instances][400] pcloudPvminstancesPostBadRequest &{Code:0 Description:bad request: calculated parameter has failed for cloud-instance 461efd70609341159d5fd6770747074b: storageType is required when not using a storage affinity policy Error:bad request Message:} on main.tf line 22, in resource "ibm_pi_instance" "power_instance": 22: resource "ibm_pi_instance" "power_instance" {So we still need to use storage type but in the
pi_instance@pi_storage_typeand use the affinity for thepi_volume.
@yussufsh we can use the volume_affinity along with volume_attach resource (We wont need pi_storage_type). However there is a issue while destroying the resources, same has been reported to community and I am expecting fix related to same in next release. Thread
You still wont be able to use the volume_attach resource as it does not work with status as WARNING. That is the main reason we are not using it.
However pi_storage_type is needed by pi_instance, so we need to pass it anyway.
resource "ibm_pi_instance" "bastion" {
pi_storage_type = "tier1"
pi_volume_ids = ibm_pi_volume.volume.*.volume_id
}
resource "ibm_pi_volume" "volume" {
pi_affinity_policy = "affinity"
pi_affinity_instance = ibm_pi_instance.bastion.pi_instance_name
}
You still wont be able to use the volume_attach resource as it does not work with status as WARNING. That is the main reason we are not using it.
However
pi_storage_typeis needed by pi_instance, so we need to pass it anyway.resource "ibm_pi_instance" "bastion" { pi_storage_type = "tier1" pi_volume_ids = ibm_pi_volume.volume.*.volume_id } resource "ibm_pi_volume" "volume" { pi_affinity_policy = "affinity" pi_affinity_instance = ibm_pi_instance.bastion.pi_instance_name }
@yussufsh Above approach leads to cyclic dependency.
Also as per doc pi_storage_type - (Optional, String) - Storage type for server deployment. Only valid when you deploy one of the IBM supplied stock images. Storage type for a custom image (an imported image or an image that is created from a VM capture) defaults to the storage type the image was created in -- According to this it should default to storage type of custom image (RHEL)
So if we want to use the affinity policy we are required to use the storage attach resource? That will not give cyclic dependency but that will have issues with the vm status.
The error on pi_storage_type above is required for stock images as that is what is supported by the automation.