Edit: Updated based on recent testing using PowerVC 1.4.3.1, Terraform v0.12.9 and terraform-provider-openstack_v1.23.0_x4
So recently I started investigating into using Terraform and its Openstack provider to deploy LPARs on Power Systems via PowerVC. Throughout this process, I ran into a few issues due to limitations in the Openstack provider. Unfortunately, the workarounds for most of the limitations result in a mismatched state between Terraform and the actual instances as many of them involve direct calls to PowerVC (PVC).
Multiattach
One of the first issues I encountered was that multiattach is NOT supported by the openstack provider. This is a known limitation with an open issue on github for it. What this means is to get around this issue for any automation workflows you would need to update and add the multiattach flag for cinder volumes directly via PowerVC API calls.
Multiattach now works with openstack_blockstorage_volume_v3, a simple multiattach = true is all that is needed. This no longer throws an error as it did in older levels.
This appears to have been added in October 2018 to the openstack provider for terraform (https://github.com/terraform-providers/terraform-provider-openstack/issues/432).
Online Extension of Volumes
Another common use case I tested was online extension of SAN volumes. This was another case that failed quickly. If you attempt to perform an online extension you will receive a error message thrown back by PVC with the message following message:
error message: {“forbidden”: {“message”: “Policy doesn’t allow volume:extend_attached_volume to be performed.“, “code”: 403}}
The way around this one again, skip terraform and perform your volume extensions directly via PVC API Calls.
This issue is also resolved now, online extension SAN of volumes is no longer an issue and appears to be fully supported as of PVC 1.4.3.1.
Storage Connectivity Group cannot be selected for compute deployment
Now this was one that really frustrated me. Most people who deploy to a system will have more then one storage connectivity group (prod, dev, test, etc) and will want to use different storage connectivity groups for different LPARs. Unfortunately, you cannot pass any attributes using the openstack provider to declare which storage connectivity group to use in PVC. Instead, you have to create multiple compute templates (templates for each SCG you want to use). After creating the templates, you will need to add an extra_spec via the openstack CLI on powervc for the template to set which SCG to use, i.e. by running: nova flavor-key medium-scg1 set powervm:storage_connectivity_group="<ID OF SCG>"
Storage Template cannot be selected for compute deployment
Again, similar to the previous issue, you cannot select storage templates either unless custom templates with specific keys are created. This is useful if you need to have things like your root volume group spread across multiple pools and these pools differ for different environments.
In this case, the extra spec you would want to set is called powervm:image_volume_type_<ID OF VOLUME FROM IMAGE>, for example, if you had an image named ‘my_aix_image’, you would need to see what volumes my_aix_image is comprised of. Each of these volumes will have an id you can see within PowerVC. Note: The following has totally made up ID’s which are not the correct length/etc for a proper example. If you saw disk 1 of your image had an id of ‘0b1ebac8-e8b7-4ab0-8adc-e248d8ddd707’ and disk 2 of your image had an id of ‘c212ddc6-51f9-43d0-988e-1793724f4b2f’ and you wanted to assign them to two storage templates, you would need to get the ID of the storage template and then run the following for each of the volumes: nova flavor-key my-custom-template set powervm:image_volume_type_<ID_OF_DISK>="<ID OF VOLUME TYPE TO ASSIGN>"
Cannot add/remove network adapters after deploy using Terraform
Again, this is a very frustrating issue, but Terraform will request destruction of your LPAR when you attempt to add/remove a network adapter. The only way I have found to get around this is to perform API calls directly to PVC.
Online & Offline Resize (flavor change) fails with Terraform
In PowerVC, one thing you’ll notice when you have SAN attached boot volumes is the template believes their is 0 gb of disk assigned to the template. Any attempt to change this will result in the LPAR not being able to be deployed via PowerVC. If you attempt to resize a disk using Terraform what you’ll see is terraform attempts to resize SAN volume and reduce disk size to 0 when done with this is done as an online activity (with the LPAR active). If you stop the LPAR and attempt to do this offline, PowerVC attempts to check if the LPAR is in ‘active’ state to perform the change and then fails. Again, the only workaround I’ve come across is to perform these tasks via API calls direct to PVC.
0 Comments