attempt to modify the number of processors in a Power VS LPAR fails with message "cloud-instance does not have the capability to set custom virtual cores"

[kdixonIBM]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform CLI and Terraform IBM Provider Version

terraform -v
Terraform v1.0.2
on linux_amd64

Affected Resource(s)

• ibm_pi_instance

Terraform Configuration Files

Please include all Terraform configurations required to reproduce the bug. Bug reports without a functional reproduction may be closed without investigation.

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please share a link to the ZIP file.
# 
# main.tf
# 
## Template to be used by the IBM Provider for Power Systems

resource "ibm_pi_key" "key" {
  pi_cloud_instance_id = var.power_instance_id
  pi_key_name          = var.ssh_key_name
  pi_ssh_key           = var.sshkey
}

data "ibm_pi_key" "dskey" {
  depends_on           = [ibm_pi_key.key]
  pi_cloud_instance_id = var.power_instance_id
  pi_key_name          = var.ssh_key_name
}

resource "ibm_pi_network" "power_networks" {
  count                = 1
  pi_network_name      = var.networks
  pi_cloud_instance_id = var.power_instance_id
  pi_network_type      = "pub-vlan"
}

data "ibm_pi_public_network" "dsnetwork" {
  depends_on           = [ibm_pi_network.power_networks]
  pi_cloud_instance_id = var.power_instance_id
}

resource "ibm_pi_volume" "volume"{
  pi_volume_size       = 20
  pi_volume_name       = var.volname
  pi_volume_type       = "tier3"
  pi_volume_shareable  = true
  pi_cloud_instance_id = var.power_instance_id
}
data "ibm_pi_volume" "dsvolume" {
  depends_on           = [ibm_pi_volume.volume]
  pi_cloud_instance_id = var.power_instance_id
  pi_volume_name       = var.volname
}

data "ibm_pi_image" "power_images" {
  pi_image_name        = var.image_name
  pi_cloud_instance_id = var.power_instance_id
}

resource "ibm_pi_instance" "pvminstance" {
  pi_memory             = var.memory
  pi_processors         = var.processors
  pi_instance_name      = var.vm_name
  pi_proc_type          = var.proc_type
  pi_migratable         = var.migratable
  pi_image_id	         = data.ibm_pi_image.power_images.id
  pi_volume_ids         = ["${ibm_pi_volume.volume.volume_id}"]
  pi_network_ids        = data.ibm_pi_public_network.dsnetwork.*.id
  pi_key_pair_name      = ibm_pi_key.key.key_id
  pi_sys_type           = var.system_type
  pi_replication_policy = var.replication_policy
  pi_replication_scheme = var.replication_scheme
  pi_replicants         = var.replicants
  pi_cloud_instance_id  = var.power_instance_id
  pi_storage_type       = var.stor_type
  pi_health_status      = "WARNING"

}

#
# variables.tf
#

variable "ibmcloud_api_key" {
  description = "Denotes the IBM Cloud API key to use"
  default     = "123456"
}

variable "ibmcloud_region" {
  description = "Denotes which IBM Cloud region to connect to"
  default     = "us-south"
}

variable "vm_name" {
  description = "Name of the VM"
  default     = "KD-demo-VM"
}

variable "vm_private_key_base64" {
  description = "The base64-encoded form of the private key used to make SSH connections to the VM"
  default     = "123456"
}

variable "power_instance_id" {
  description = "Power Virtual Server instance ID associated with your IBM Cloud account (note that this is NOT the API key)"
  default     = "123456"
}

variable "memory" {
  description = "Amount of memory (GB) to be allocated to the VM"
  default     = "4"
}

variable "processors" {
  description = "Number of virtual processors to allocate to the VM"
  default     = "1"
}

variable "proc_type" {
  description = "Processor type for the LPAR - shared/dedicated"
  default     = "shared"
}

variable "ssh_key_name" {
  description = "SSH key name in IBM Cloud to be used for SSH logins"
  default     = "ssh-key"
}

variable "shareable" {
  description = "Should the data volume be shared or not - true/false"
  default     = "true"
}

variable "networks" {
  description = "List of networks that should be attached to the VM"
  default     = "kd-public5"
}

variable "system_type" {
  description = "Type of system on which the VM should be created - s922/e880"
  default     = "s922"
}

variable "migratable" {
  description = "Can the VM be migrated - true/false"
  default     = "true"
}

variable "image_name" {
  description = "Name of the image from which the VM should be deployed"
  default     = "7200-05-01"
}

variable "replication_policy" {
  description = "Replication policy of the VM"
  default     = "none"
}

variable "replication_scheme" {
  description = "Replication scheme for the VM"
  default     = "suffix"
}

variable "replicants" {
  description = "Number of VM instances to deploy"
  default     = "1"
}

variable "stor_type" {
  description = "Storage type = Tier1 or Tier3"
  default     = "tier3"
}


variable "sshkey" {
  description = "Public ssh key"
  default     = "ssh-rsa 123456"

}

variable "volname" {
  default = "kdvol99"
  description = "Name of the volume"
}

Debug Output

Panic Output

Expected Behavior

These files were used successfully to create a Power VS LPAR. Then the processor value (pi_processors = var.processors) was changed from "1" to "2", but the apply failed. The expectation was that the number of processors would have been altered.

Actual Behavior

terraform apply
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
~ update in-place

Terraform will perform the following actions:

ibm_pi_instance.pvminstance will be updated in-place
~ resource "ibm_pi_instance" "pvminstance" {
id = "8336a0a7-2d20-49f0-a653-22355b3c1bf8/b2d0e34c-2f71-4fcc-8524-84f7b2beb882"
~ pi_image_id = "f9f8b757-7200-4e0c-9dcc-cd2277669140" -> "193d584a-31dc-449b-970a-f2e56548fd3b"
~ pi_migratable = false -> true
~ pi_processors = 1 -> 2
# (29 unchanged attributes hidden)
}

Plan: 0 to add, 1 to change, 0 to destroy.

Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.

Enter a value: yes

ibm_pi_instance.pvminstance: Modifying... [id=8336a0a7-2d20-49f0-a653-22355b3c1bf8/b2d0e34c-2f71-4fcc-8524-84f7b2beb882]
ibm_pi_instance.pvminstance: Still modifying... [id=8336a0a7-2d20-49f0-a653-22355b3c1bf8/b2d0e34c-2f71-4fcc-8524-84f7b2beb882, 10s elapsed]
╷
│ Error: failed to update the lpar with the change Failed to Update PVM Instance b2d0e34c-2f71-4fcc-8524-84f7b2beb882 :[PUT /pcloud/v1/cloud-instances/{cloud_instance_id}/pvm-instances/{pvm_instance_id}][400] pcloudPvminstancesPutBadRequest &{Code:0 Description:bad request: cloud-instance 93882c0135004de0a7fa1a4861a16ad9 does not have the capability to set custom virtual cores Error:bad request Message:}
│
│ with ibm_pi_instance.pvminstance,
│ on main.tf line 45, in resource "ibm_pi_instance" "pvminstance":
│ 45: resource "ibm_pi_instance" "pvminstance" {
│
╵

Steps to Reproduce

1. terraform apply

Important Factoids

References

• #0000

[yussufsh]

Thanks for creating the issue. As per discussion with the service broker team one thing is clear that updating processors does not need additional capabilities on the service instance. Everyone should be able to increase/decrease the processors and is enabled by default.

However setting custom virtual cores needs additional capability that is not enabled by default. As per the error message it seems the Terraform code is trying to change the virtual cores in case of change in the processor.

I found the below code that is introducing this bug.

terraform-provider-ibm/ibm/resource_ibm_pi_instance.go

Lines 670 to 676 in f87de95

	body := &models.PVMInstanceUpdate{
	Memory: mem,
	ProcType: processortype,
	Processors: procs,
	ServerName: name,
	}
	body.VirtualCores = &models.VirtualCores{Assigned: &assignedVirtualCores}

@surajibm @surajsub is setting virtual core needed while updating the processor and memory? If yes then we can check if there is change in the virtual core resource data OR we could simply remove it if not needed. Let me know your thoughts, I can work on implementing the fix.

[jwcroppe]

@yussufsh Agree with your comment - it looks like the issue is that the provider code is attempting to post an update (to the same value) the virtual cores when the user didn't actually change it - they were just changing the processors, which should be allowed.

Looks like the code that determines which fields changed needs to be updated and only update the appropriate fields in the PowerVS API call.

[surajsub]

There is a change that's already available in my local provider was not pushed to the ibm cloud provider. I'll work with @yussufsh to pull that in.

[yussufsh]

After discussing with Suraj and running some tests found that the virtual cores are needed to be set along with the processors. So the current PR needs to be updated to include virtual cores only when the capability is enabled for the service instance.