Hi there,
It looks like there's the same issue as https://github.com/hashicorp/terraform/issues/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"
v0.6.15
Closed by #6649
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
Ping. Could you please open the issue? I'm using terraform 0.6.16 and got the same issue.
cc @apparentlymart
@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"]
}
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.
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.
Most helpful comment
@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: