wgebis / terraform-provider-mailgun

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

External password "change" causes the password to reset, making it impossible to use it for output

Tomaszal opened this issue · comments

Terraform Version

Terraform v1.2.3
on linux_amd64
+ provider registry.terraform.io/wgebis/mailgun v0.7.2

Affected Resource(s)

  • mailgun_domain_cedential

Terraform Configuration Files

# Create a new Mailgun credential
resource "mailgun_domain_credential" "foobar" {
    domain = "toto.com"
    login = "test"
    password = "supersecretpassword1234"
    region = "us"

    lifecycle {
        ignore_changes = [ "password" ]
    }
}

Expected Behavior

After the initial application, the password should not cause a Objects have changed outside of Terraform message and should keep the state of the initial password.

Actual Behavior

After the initial application, Terraform detects an external password change due to the Mailgun API not retrieving previously created secrets (as specified in the documentation). The documentation suggests using ignore_changes. However, as per hashicorp/terraform#28803 (comment), ignore_changes doesn't actually ignore changes in the remote system, only in the configuration. Due to this issue, it is impossible to use the password as an output, as it will only work on the first application.

Steps to Reproduce

  1. terraform apply
  2. terraform apply

References

I'm not sure how Terraform or this provider work under the hood, but would it be possible to make password an "input only" attribute?

Same issue here, Is there any solution? Maybe another provider?

Hi there,
this is well-known issue, password passed during resource will not be returned anymore by Mailgun API. That's why it detects changes. So far the best workaround is to mark this property as ignored.
BTW: It's also common to use dedicated resource for handling creation of credentials.
Best,
W

Hi, thanks for the response. I understand that this is an API limitation, and that the proposed workaround is to mark the property as ignored with ignore_changes. However, as stated in the issue, that doesn't do quite what what's expected. The ignore_changes properties will simply not try to update the resources if local properties change. However, it will still detect the changes outside of Terraform and update the local state.

This means that if you specify a password on a credential resource you will have to run terraform apply twice, as the first time it'll set the correct password in Mailgun and in the local state, where as the second time it will think that the Mailgun password changed (as the API returns an empty one) and update the local state to have the empty password.

For now, I have simply added a variable where I set the password which I can use in the credential resource and use it in an output. However, that doesn't solve the issue of the local state being needlessly and wrongly updated.

My proposal would be to modify the API calls, so that if the returned response includes an empty password, it would be replaced by the password provided in the resource before being returned to Terraform.

Hi!

My proposal would be to modify the API calls, so that if the returned response includes an empty password, it would be replaced by the password provided in the resource before being returned to Terraform.

Still, how can I detect the change of password in remote system? There is no such option using Mailgun API. I can only rely on local changes.

@Tomaszal You can also try newest version v0.7.4, I made some improvements, perhaps it will solve your issues.

@wgebis Just got around to testing this and it seems to work great for new/modified resources, even removing the need for ignore_changes entirely! Only issue that I noticed is that the previously saved "empty" passwords in the state don't seem to update after this improvement. However, simply re-creating the resources (or even just changing their passwords) updated the password in the state to the correct one. Perhaps there could be check that would update the passwords in the state if they were empty. Otherwise simply updating the documentation to mention this fix would work too.