-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: Updated Guidance for when users are unable to delete cluster and backup schedule with backup compliance policy enabled #1790
Conversation
Doc Fix related HELP-53760. Offers alternative approaches to help unblock customers when they are unable to delete cluster and backup schedule with backup compliance policy enabled
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great start! I left some comments on how you can improve the clarity and tone of the text here.
* Third, another alternative is to modify the `mongodbatlas_cloud_backup_schedule` resource by replacing all the references to the `mongodbatlas_advanced_cluster` or `mongodbatlas_cluster` resource with the underlying values. This would enable deleting the cluster resource first, but requires obtaining values from the state to do the appropriate replacements. | ||
* Lastly, as a final resort taking into account the limitations, we recondmend: | ||
* Remove the `mongodbatlas_cloud_backup_schedule` resource from the state using `terraform state rm mongodbatlas_cloud_backup_schedule.backup_retention_policy` | ||
* Remove the `mongodbatlas_cloud_backup_schedule` and `mongodbatlas_advanced_cluster` or `mongodbatlas_cluster` resource for the terraform configuration script and apply changes. Now only the cluster delete operation is called and runs successfully. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* Remove the `mongodbatlas_cloud_backup_schedule` and `mongodbatlas_advanced_cluster` or `mongodbatlas_cluster` resource for the terraform configuration script and apply changes. Now only the cluster delete operation is called and runs successfully. | |
* Remove the `mongodbatlas_cloud_backup_schedule` and `mongodbatlas_advanced_cluster` or `mongodbatlas_cluster` resource for the terraform configuration script and apply changes. Now only the cluster delete operation is called and runs successfully. |
So its unclear to me what the correct combination of removal is required here -- is it mongodbatlas_cloud_backup_schedule
and mongodbatlas_advanced_cluster
, or mongodbatlas_cloud_backup_schedule
and mongodbatlas_cluster
, or
an option between both mongodbatlas_cloud_backup_schedule
and mongodbatlas_advanced_cluster
, or mongodbatlas_cluster
?
A comma is needed to indicate the correct combination here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is all instances of mongodbatlas_cloud_backup_schedule
and references customer has to either advanced_cluster or cluster, updated with parenthesis if this is more clear? Reason being mongodbatlas_cluster
resource is being sunset next year so most users will be focused on mongodbatlas_advanced_cluster
resource over the long-term
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that case, a comma should go after mongodbatlas_advanced_cluster
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makes sense. updated @kyuan-mongodb. appreciate all the help here (as always!)
Co-authored-by: kyuan-mongodb <[email protected]>
Co-authored-by: kyuan-mongodb <[email protected]>
Co-authored-by: kyuan-mongodb <[email protected]>
Co-authored-by: kyuan-mongodb <[email protected]>
Co-authored-by: kyuan-mongodb <[email protected]>
Co-authored-by: kyuan-mongodb <[email protected]>
Co-authored-by: kyuan-mongodb <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just a small comment to consider
* `mongodbatlas_cloud_backup_schedule` fails when you delete an Atlas cluster because an existing backup compliancy policy is enabled, which is expected. | ||
We first suggest disabling `mongodbatlas_backup_compliancy_policy` resource which requires contacting MongoDB Support and completing an extensive verification process. | ||
* Second, if the first suggestion is not possible, we suggest changing the order in which terraform deletes the resource. This might not always be possible since the `mongodbatlas_cloud_backup_schedule` resource is referencing attributes from the `mongodbatlas_advanced_cluster`, or `mongodbatlas_cluster resource`, and therefore has to delete the backup schedule before deleting the cluster resource. This dependency must be defined as stated in the `mongodbatlas_cloud_backup_schedule` in the [documentation](https://registry.terraform.io/providers/mongodb/mongodbatlas/latest/docs/resources/cloud_backup_schedule). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I am not sure about suggesting to disable backup_compliancy_policy
as the first option, as this is likely the most time consuming and not ideal. Was the intention here to provide more context on the limitations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be for the customer to determine the effort to reward ratio per their organization needs. Agree for most users this is likely most time consuming, but by contacting MongoDB Support and user has completed extensive verification process, they is a high probability that our Support team will be able to help user to delete resource directly. Also serves has helpful reminder of why this limitation on deleting mongodbatlas_cloud_backup_schedule
exists on the first place for users with mongodbatlas_backup_compliance_policy
enabled
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM % minor grammar fix!
Co-authored-by: kyuan-mongodb <[email protected]>
Doc Fix related HELP-53760. Offers alternative approaches to help unblock customers when they are unable to delete cluster and backup schedule with backup compliance policy enabled
Description
Please include a summary of the fix/feature/change, including any relevant motivation and context.
Link to any related issue(s): https://jira.mongodb.org/browse/HELP-53760
Type of change:
Required Checklist:
Further comments