Apply wants to replace all resources after upgrade to 0.13.3

[johnlane]

I have just upgraded from v0.12.24 to v0.13.3. Prior to the upgrade terraform apply reported no changes. After the upgrade, I have a clean terraform init. Now, when I do terraform apply it wants to replace all resources citing the image value as the thing forcing change:

 image             = "sha256:ff4ee4caaa237174080c0d545f7542c8b851d2e9b955d740ddc51e7737839cb5" -> "portainer/portainer:1.23.0" # forces replacement

I believe I followed the documented upgrade procedure, I really don't want to cause an unnecessary replacement of all resources. Is there a way to fix this or work around it ?

I am using the local backend. I've tried terraform refresh and also destroying and recreating a single resource (using -target) - I can destroy and recreate the resource but it's still being identified as different due to the image difference.

If I do terraform state pull the images are identified as a sha whereas terraform apply identified them by name.

I've just noticed it is only docker resources. Other resources are fine. It's probably to do with the docker provider, I'll do some more research and then close this out if I find that's the case.

692 $ terraform --version
Terraform v0.13.3

[apparentlymart]

Hi @johnlane! Sorry for this odd behavior.

I share your suspicion that this is something related to the docker provider rather than to Terraform Core. Specifically, it seems like the provider has changed its representation of this image argument in a way that no longer matches what you have in your configuration. If you upgraded the docker provider at the same time as upgrading Terraform then that could cause a change in provider behavior to seem like a change in Terraform provider.

hashicorp/terraform-provider-docker#291 seems like a similar symptom to what you are seeing here. Your output doesn't include a portainer/portainer:1.23.0@ prefix, but I wonder if that would be just because your particular docker server doesn't have the portainer/portainer:1.23.0 tag cached locally, and so it only knows the image hash.

I'm going to close this for now because I think we should see how hashicorp/terraform-provider-docker#291 turns out first. If the Docker provider team ends up determining that this is a Terraform Core issue then we'd be happy to dig in some more if you or they can open an issue with some more details on how to reproduce it, as requested in our bug report template.

Thanks for reporting this!

[johnlane]

Thanks @apparentlymart for commenting on this issue. I came to pretty much the same conclusion myself, and did some background reading. My config contains lines like this:

resource "docker_container" "portainer" {
  image   = "portainer/portainer:1.23.0"
  ...

I read up on this last night and, despite the many tutorials using the above form, the documentation shows having a reference to an image resource:

   image = "${docker_image.ubuntu.latest}"

and configuring that image resource to specify the image name. I don't know if or when the documentation changed to be like that but I don't think I would not have done that if the documentation at the time said to do that. Although git-blame shows that to not have changed since 2015 so I don't know (I started this Terraform config late last year). And I can't find anything alluding to this change in behaviour in the provider's changelog.

I just downgraded the Docker provider to 2.6.0 and I once again have a clean terraform apply. So definitely an issue with the Docker provider. I'm not sure why upgrading Terraform caused my docker provider to be upgraded (probably a lack of specificity in my config I guess).

Apart from this issue, my upgrade was pretty painless. I just had to update required_providers configurations and do this:

terraform state replace-provider registry.terraform.io/-/docker registry.terraform.io/terraform-providers/docker

[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.