Openstack provider : after image upgrade, refresh fails

[fdebonneval]

Hi,
I deployed a stack on our Openstack env, everything went well.
Our ops team upgraded the Ubuntu image I used to boot my vms (image uuid changed).
The image ID changed so when terraform tried to refresh the local state file, I had an error because the original image was not available anymore in Glance catalog.

I'am now stuck, neither "plan", "destroy", "apply" go through. It ends with the error :
Error refreshing state: 5 error(s) occurred:

• 1 error(s) occurred:
• Expected HTTP response code [200] when accessing [GET https://compute.fr1.cloudwatt.com/v2/1b1286db216e403694802b41c4137182/images/cc2e31fc-c24d-4905-bb45-1d57794a4f3c], but got 404 instead
  {"itemNotFound": {"message": "Image not found.", "code": 404}}
  [...]

[jtopjian]

@fdebonneval Did you use the UUID in your Terraform config? Or did you use a "common" name such as "Ubuntu 14.04"?

image_id = "ad091b52-742f-469e-8f3c-fd81cadf0743"
vs
image_name = "Ubuntu 14.04"

Most cloud providers will keep the same "common" name when doing an image update. This way, though the UUID may change, the name used to reference the image stays the same.

If you used the UUID, you may be able to change it in the Terraform state file, but I'm not 100% sure about that.

If you didn't use the UUID, though, let me know. I'm quite curious to see why this error would occur and if it's possible to fix.

[fdebonneval]

Hi Jo,

Thanks for tour concern about my issue.

I used the uuid in my .tf stack.
I tried to update the uuid in the state file without succes.

It seems that in the "cache update" phase terraform collects the running
vm's metadatas, including the original image uuid.

Then it stops because it finds a diff with the new uuid.

To quick fix, I manually destroyed the vms and run "apply".

Foucault
Le 8 juin 2015 22:41, "Joe Topjian" [email protected] a écrit :

@fdebonneval https://github.com/fdebonneval Did you use the UUID in
your Terraform config? Or did you use a "common" name such as "Ubuntu
14.04"?

Most cloud providers will keep the same "common" name when doing an image
update. This way, though the UUID may change, the name used to reference
the image stays the same.

If you used the UUID, you may be able to change it in the Terraform state
file, but I'm not 100% sure about that.

If you didn't use the UUID, though, let me know. I'm quite curious to see
why this error would occur and if it's possible to fix.

—
Reply to this email directly or view it on GitHub
#2189 (comment)
.

[jtopjian]

Just re-reviewing this issue. I think it can be closed since this really isn't a bug in the code. It's an unfortunate side-effect of referencing images by UUID and having the image yanked from the image catalog -- so totally outside of Terraform.

[phinze]

SGTM - thanks @jtopjian!

[cpitman]

I just ran into this issue, and I'm not sure I agree. Couldn't terraform handle this more gracefully, and assume that if the image is not found it no longer exists? Is there any reason not to proceed with planning/applying on the assumption that the image has changed?

[phinze]

Hi @cpitman - reviewing again, I think you're right that TF shouldn't error out on refresh / plan, even if the image does disappear out from under us. Reopening so we can take a second look at the failure mode here.

[jtopjian]

The reason I brushed this off as a non-TF issue was that this would effectively make image_id and image_name "optional" in the sense that "it's OK if an image that the user chose cannot be found", which, of course, would prevent the instance from even launching.

However, after re-re-reviewing all of the above, I do see that I overlooked the obvious: maybe the implementation for this would all take place during the "update" phase?

So, during creation, error out if an image cannot be found. But during the update, forcefully make the image data (Image Not Found) if an image cannot be found. This is the approach the OpenStack dashboard takes.

Is this a suitable fix? Or is there a pattern/solution more closer to the Terraform core that should be used? Is this situation present in any other provider, and if so, how is it resolved there?

[fdebonneval]

Looks perfect aproach to me.

Thx
Foucaut
Le 5 sept. 2015 6:22 AM, "Joe Topjian" [email protected] a écrit :

The reason I brushed this off as a non-TF issue was that this would
effectively make image_id and image_name "optional" in the sense that
"it's OK if an image that the user chose cannot be found", which, of
course, would prevent the instance from even launching.

However, after re-re-reviewing all of the above, I do see that I
overlooked the obvious: maybe the implementation for this would all take
place during the "update" phase?

So, during creation, error out if an image cannot be found. But during the
update, forcefully make the image data (Image Not Found) if an image
cannot be found. This is the approach the OpenStack dashboard takes.

Is this a suitable fix? Or is there a pattern/solution more closer to the
Terraform core that should be used? Is this situation present in any other
provider, and if so, how is it resolved there?

—
Reply to this email directly or view it on GitHub
#2189 (comment)
.

[ghost]

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.