 |
Reclaim resources
|
This is a quick follow-up to my "
To restore or delete" post in which I discussed
IBM Cloud resource reclamations and shared some tricks. Today, I have some more details and also want to share with you my best practices on handling resources.
Reclamation states
As described in my previous post, you can list the pending resource reclamations with the CLI command ibmcloud resource reclamations. Here is a recent screenshot of running that command:
 |
Resource reclamations in different states
|
The screenshot above shows several resource in my account which are SCHEDULED
for reclamation. The target date indicates the scheduled deletion. The
Cloudant database instance, shown as second from the bottom, is in the
state RECLAIMING because I used "ibmcloud resource reclamation-delete" just some seconds before. The last entry, a Certificate Manager instance, shows RESTORE_FAILED
and was kept beyond the target date. Thus, I could investigate further.
After creating the screenshot, I used "reclamation-delete" to
permanently delete it. Then, it was no longer available and shown in the
list.
Lessons learned and best practices
Fully
deleting a resource which is SCHEDULED always works, the ability to
restore it depends on whether the original "context" is available. The RESTORE_FAILED in
the scenario above happened because I deleted the service and its
resource group. Thus, the service instance could not be restored and the
process failed.
Some
services require a unique instance name. Depending on the service,
instances scheduled for deletion might be considered for the uniqueness
check. Reprovisioning the resource with the same name could fail.
Based on my experience with resource reclamations and cloud security, I developed my best practices for handling resources:
Provision and delete resource groups as separate steps, e.g., when automating deployments with Terraform or Schematics. That way, the resource group could stay around and would allow to restore deleted resources.
Apply
a naming scheme that guarantees unique resource names. This avoids
naming conflicts in teams, projects, or sometimes even across accounts. I
usually try to include information about the project, the resource
location, dates if applicable, and more.
Conclusions
Resource
reclamations are a safeguard to not accidentally delete still used
services and data. It is possible to retrieve details on those resources
and restore them if needed. The devil is in the details - as usual. Thus, it is a good opportunity to look at your own best practices in how to provision and organize resources. I shared mine.
To read more on the topic, I would recommend these two:
If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik) or LinkedIn.
