When a compositions gets deleted, all composed resources are deleted at the same time, meaning that if one of them depends of the other (e.g a Database resource depending on the server), if the server gets deleted first the Database MR will be stuck on deletion, even though in the cloud it's actually deleted.
I understand there is a Usage resource that can help the issue, however, in clouds like Azure were everything is nested, it quickly spirals out of control. A situation we have is subscription -> resource group -> sql server/key vault -> database/ secret. Putting every relationship descriptively through a Usage quickly becomes cumbersome and, in my opinion, goes against Kubernetes' ideals.
How could Upjet help solve your problem?
I think at time of MR definition in the provider, there should be an option to put a parent relationship to another MR, and when the provider tries to delete the resource, if it gets an errors, should check for existence of parent resource. If the parent resource is missing, the child resource is deleted.
Something like
p.AddResourceConfigurator("azurerm_monitor_smart_detector_alert_rule", func(r *config.Resource) {
// like references to another resource
r.References["action_group.ids"] = config.Reference{
TerraformName: "azurerm_monitor_action_group",
Extractor: rconfig.ExtractResourceIDFuncPath,
}
r.References["scope_resource_ids"] = config.Reference{
TerraformName: "azurerm_application_insights",
Extractor: rconfig.ExtractResourceIDFuncPath,
}
/// would reference another tf resource
r.Parent("azurerm_application_insights")
})
What problem are you facing?
When a compositions gets deleted, all composed resources are deleted at the same time, meaning that if one of them depends of the other (e.g a Database resource depending on the server), if the server gets deleted first the Database MR will be stuck on deletion, even though in the cloud it's actually deleted.
I understand there is a Usage resource that can help the issue, however, in clouds like Azure were everything is nested, it quickly spirals out of control. A situation we have is subscription -> resource group -> sql server/key vault -> database/ secret. Putting every relationship descriptively through a Usage quickly becomes cumbersome and, in my opinion, goes against Kubernetes' ideals.
How could Upjet help solve your problem?
I think at time of MR definition in the provider, there should be an option to put a parent relationship to another MR, and when the provider tries to delete the resource, if it gets an errors, should check for existence of parent resource. If the parent resource is missing, the child resource is deleted.
Something like