mongodbatlas_cloud_provider_snapshot_backup_policy restore_window_days (optional value) is being set even when omitted in resource config
#290
Comments
themantissa
changed the title
mongodbatlas_cloud_provider_snapshot_backup_policy fails when optional parameter restore_window_days is omittedmongodbatlas_cloud_provider_snapshot_backup_policy restore_window_days (optional value) is being set even when omitted in resource config
|
Thank you @bastiandg, it is indeed an optional value and should be not sent. And what is being sent is out of a valid range. |
|
@bastiandg we've released a preview version that should allow you to test if this fixes the issue. If you can confirm we'd appreciate it. |
|
Hey @themantissa and @PacoDw thanks for implementing the fix. The first thing I tried was to update an existing cluster with The next thing I tried was to completely recreate the cluster backup policy. And the apply itself works without an issue, but oddly enough the restore_window_days is set to My best guess is that the API from Atlas sets a default value without the provider picking that up properly. |
|
@bastiandg thank you, this is helpful. Before you did the first try did you refresh all state? I ask because I think part of the problem here may be how we had to implement the cloud backup policy. As you note on the second part of your comment above, Atlas sets a default value - not just for restore_window_days but as soon as Cloud Backup is enabled there is a policy/schedule created by default within Atlas. If you look at the underlying API documentation you can see that Cloud Backup Policy/Schedule has two methods - GET and PATCH. There is no POST as you create a Cloud Backup Policy when you enable backup and not DELETE because you remove it by turning backup off. So here's what we did in the provider to get around this: Most importantly thought, were you now able to at least set restore_window_days to 1? Did that second apply work? |
|
I didn't run an explicit
-> No change is recognized. I don't mind the slight inconsistency here, as it is a very rare edge case, that is also easy to resolve by re-adding the value. Thanks for the explanation on the API in the background! Beside what you said, most of my confusion was my own fault. The documentation says:
What I read into it was: "If you don't set this value, 0 will be assumed". So I think, yes for both cases above, it could be helpful to add information on which values are used when. Something like: In case it has been configured before, the configuration is left untouched. If a new backup policy is created, the default value of Changing the implicitly configured Coming back to the original issue, it is fixed and this can be closed. Thanks a lot for your work and your explanations. |
|
@bastiandg thank you for the helpful response! Definitely realizing we have some room for improvement here in how we document backup, hopefully we can tackle soon but very glad the original issue is fixed! I'll close this issue but let us know if anything else comes up. Cheers! |
Terraform CLI and Terraform MongoDB Atlas Provider Version
Terraform Configuration File
Steps to Reproduce
restore_window_daysinmongodbatlas_cloud_provider_snapshot_backup_policyconfigurationterraform initterraform applyExpected Behavior
Successful apply
Actual Behavior
Debug Output
Additional Context
As seen in the debug output the
restoreWindowDaysare sent to atlas even though it was not configured. Explicitly settingrestore_window_days = nullresults in the same behavior.The text was updated successfully, but these errors were encountered: