AWS OpsWorks ssh_key in app_source keeps re-applying

[iroller]

Hi there,

It looks like there's the same issue as #3635 existing in aws_opsworks_application -> app_source -> ssh_key.

Config:

resource "aws_opsworks_application" "app" {
  name        = "application"

  app_source = {
    type     = "git"
...
    ssh_key  = "${file("~/.ssh/private-key")}"
  }

On terraform plan/apply it keeps re-applying the ssh_key even though it's the same.

Also if it's filtered it shouldn't be displayed:

$ terraform plan

~ aws_opsworks_application.app
    app_source.0.ssh_key:  "*****FILTERED*****" => "-----BEGIN RSA PRIVATE KEY--- ... my-private-key-here"

Terraform Version

v0.6.15

Affected Resource(s)

• aws_opsworks_application
• app_source

[stack72]

Closed by #6649

[iroller]

Sad but the pull request wasn't complete. There's no support for "WriteOnly" attributes for aws_opsworks_application. It's only supported in aws_opsworks_layers.

To get that bug actually fixed we'll need to add "WriteOnly" support to the main schema or there should be a separate struct, e.g. opsworksApplicationAttribute for "app_source" just like it's done for aws_opsworks_layers's opsworksLayerTypeAttribute.

cc @apparentlymart

[wookieb]

Ping. Could you please open the issue? I'm using terraform 0.6.16 and got the same issue.
cc @apparentlymart

[u2mejc]

@wookieb There are a few of these immutable resources. As a stop gap, I've avoided these issues by simply using the lifecycle ignore_changes feature, like this:

lifecycle {
    ignore_changes = ["custom_cookbooks_source.0.ssh_key"]
  }

[solinv]

The lifecycle ignore_changes workaround @u2mejc proposed doesn't work for us.

Whenever another attribute of the resource (aws_opsworks_stack in our case) changes, custom_cookbooks_source.0.ssh_key will be set to empty string in OpsWorks, effectively breaking the whole thing for us as I can't see any kind of workaround.

If interested, I have a very minimal stack.tf that I could enhance with comments on how to reproduce. Using 0.6.16.

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