aws_dms_replication_task replication_task_settings always reports as needing modification #1513
Comments
|
Similar (likely the same) issue in 0.10.7 This causes an issue even if you omit replication_task_settings. If you omit the replication_task_settings and run apply multiple times you'll get an error on subsequent applications: 'InvalidParameterCombinationException: No modifications were requested on the task' It seems that the tfstate file contains all the settings' values and sees that as differing from "" (nothing), but when it attempts to modify the task it (rightly) notices there's no real modification. |
|
The real problem is terraform missing If you disable If you enable If it's aws api's restrict, I think terraform should ignore |
|
@monsterxx03 That's what I did until I realized I could simply use "ignore_changes", which acts as an adequate workaround for the time being. |
|
@sforcier I'm trying to do the same now, but I was wondering about the correct syntax I have this within my aws_dms_replication_task
Did it resolve your problem? I'm still getting the same error... |
|
@donalddewulf You have to ignore entire arguments, e.g. I'm not sure of how to ignore specific changes within the text value of the |
|
@sforcier Yes that makes sense, thanks! |
|
Has anyone found a workaround for this? |
|
I ran into the same problem. Everytime I run Although there was no change at all. And yes, I have configured Although Therefore +1 |
|
Stil present in
|
|
Facing the same issue with aws_dms_replication_task |
|
still present in the 'workaround' works fine for me (until i need to change the task settings ^^) |
|
HI is there any update on this?? I still seem to get the destroy issue as well, even with: } The error actually says the 'id' (forces new resource). The id is is made of of a local var and suffix which dont change? Im on v0.11.11 as well, v1.59 of AWS provider. Also both the table mappings and settings are from template files. These dont change when terraform complains that the 'id' has changed forcing the resource to be recreated. |
|
Agreed logging must be enabled, thats not an option |
|
Anyone? Sort of a urgent, my resource always want to recreate itself :( |
|
I just ran into this too, so let me recap concisely. Today, Terraform doesn't support JSON key comparison, just string. (Please correct me if I'm wrong and I'll put a PR up to fix this issue.)
This "setting" is not a Terraform resource argument, just key value in the json blob that Terraform passes to the API. So knowing that in the middle of your json blob are two strings, that on creation can't be there, and after creation (when logging is enabled), have to be there, you could get fancy with conditional interpolation ( My work around: On creation, use We use @apparentlymart An chance the next minor (semantic version, major for TF) release will support JSON key value comparison / formated diffs so it's legible and we don't have to worry about keys moving place in the blob? |
|
FYI - Ive noticed not to use any capitals in DMS related resource names. They get all made lowercase and then TF thinks its always changed. Annoying - but its a DMS thing, so make sure resources are lowercase! |
|
Terraform v. 0.11.11 Successfully applied, subsequent plans/applies do not detect any changes. |
This is not a solution for me. I still have the same problem. |
|
Has anyone found a workaround for this with TFv0.12.6? Even "lifecycle.ignore_changes" settings are not working. Docs - |
|
@vivekyad4v For us, the |
I think you can override DiffSuppressFunc (https://www.terraform.io/docs/extend/schemas/schema-behaviors.html#diffsuppressfunc) here https://github.com/terraform-providers/terraform-provider-aws/blob/master/aws/resource_aws_dms_replication_task.go#L63 with code that parses the JSON and removes the logging keys if they exist |
|
I've got a patched function that @nijave mentions that I've tested locally against a DMS endpoint I was also having problems with. I'd like to have something like this upstream but I'm still a terraform v11 user so I've built this off the was provider 2.25.x Ignored changes is not good enough, otherwise how can you ensure terraform keeps pushing new changes. Its a bit of a reach calling this a Terraform bug as well, maybe unexpected behaviour as AWS is creating the CloudWatch stream and CloudWatch group under the water and AWS does not allow this to be set. In fact when creating a lot of this through Terraform and not the UI you need to also create some related IAM resources for all of this to work properly. func suppressEquivalentJsonDiffsExcludeFields(k, old, new string, d *schema.ResourceData) bool {
var dat map[string]interface{}
if err := json.Unmarshal([]byte(old), &dat); err != nil {
return false
}
loggingOptions := dat["Logging"].(map[string]interface{})
log.Println("The Normal Logging Options", loggingOptions)
// Clean Cloudwatch Settings from old Output due to AWS API returning it
delete(loggingOptions, "CloudWatchLogGroup")
delete(loggingOptions, "CloudWatchLogStream")
cleanedJson, err := json.Marshal(dat)
if err != nil {
fmt.Println(err.Error())
return false
}
old = string(cleanedJson)
ob := bytes.NewBufferString("")
if err := json.Compact(ob, []byte(old)); err != nil {
return false
}
log.Println("The OB", ob)
nb := bytes.NewBufferString("")
if err := json.Compact(nb, []byte(new)); err != nil {
return false
}
log.Println("The NB", nb)
return jsonBytesEqual(ob.Bytes(), nb.Bytes())
} |
Was this working? I had something very similar and Terraform 0.11.13 still wanted to update the field even though it showed no diff for the field (just that the field needed changed). It may not be a bug in Terraform but it's definitely a bug in the provider since it's trying to perform bogus changes |
|
Yes this one did work for me as it’s a matter of removing the two cloudwatch keys. I agree the provider itself has the issue. I wonder whether terraform 11 can ignore maps as in version 12 described here hashicorp/terraform#21857 so I will give that a try a bit later. |
|
We just faced this issue. What I think may be the solution is to allow ignore_changes to accept json path relative to object fields. |
|
21 upvotes on the prior comment, is that enough to get merged? the work arounds for this are annoying- lifecycle ignored means you can't ever update the task settings after it is created. we used a hash of the json file as part of the task name, but this does result in new tasks being created each time. please react to the prior comment... |
|
This has been released in version 3.36.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template for triage. Thanks! |
|
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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks! |
ghost
locked as resolved and limited conversation to collaborators
and others
Terraform Version
Terraform v0.10.2
Affected Resource(s)
Terraform Configuration Files
Expected Behavior
After running terraform apply, a subsequent run of terraform plan should indicate no changes needed.
Actual Behavior
The plan continually requires modifications as seen bellow. It appears that the settings from my terraform project are compared against the full set of properties with default values pulled from AWS. Ideally, you should be able to set only the properties that differ from the default.
Steps to Reproduce
terraform applyterraform planImportant Factoids
N/A
References
N/A
The text was updated successfully, but these errors were encountered: