provider/openstack: Boot From Volume and Image Handling Fixes #3232
Conversation
jtopjian
changed the title
|
Can I do anything else to move this PR along? |
|
+1 I'm stuck on the same issue where I need to specify an image name or id even though I am booting from volume |
This commit fixes the previously broken "boot from volume" feature. It also adds an acceptance test to ensure the feature continues to work. The "delete_on_termination" option was also added.
This commit cleans up the volume and block device handling in the instance resource. It also adds more acceptance tests to deal with different workflows of attaching and detaching a volume through the instance's lifecycle. No new functionality has been added.
This commit cleans up areas that configure the image_id and image_name. It enables the ability to not have to specify an image_id or image_name when booting from a volume. It also prevents Terraform from reporting an error when an image name is no longer able to be resolved from an image ID. This usually happens when the image has been deleted, but there are still running instances that were based off of it. The image_id and image_name parameters no longer immediately take a default value from the OS_IMAGE_ID and OS_IMAGE_NAME environment variables. If no other resolution of an image_id or image_name were found, then these variables will be referenced. This further supports booting from a volume. Finally, documentation was updated to take into account booting from a volume.
|
I was really hoping to merge this today, but it looks like there's been a change with how Boot From Volume is handled in OpenStack Liberty. I have a patch into Gophercloud to get it resolved: rackspace/gophercloud#509 |
|
Gophercloud has been fixed. Doing one final review of the code and running acceptance tests, then merging. @phinze This will require the latest commit for Gophercloud. Does that need noted anywhere for building the releases? |
…-fixes provider/openstack: Boot From Volume and Image Handling Fixes
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
ghost
locked and limited conversation to collaborators
Fixes #3206
Fixes #2189
The above two issues had some overlap with regard to how images were handled. Because of the overlap, I felt it was more efficient to create a PR that fixed both.
For individual fixes of the above two issues, see #3225 and #3202, however a third PR would need to be created after both were merged to finish off the changes.
The commit message in each commit of this PR should explain the changes, though please let me know if any clarification is needed.