Make child resources parent-aware during deletion

[Mikel-Landa]

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

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")
})

[jeanduplessis]

@Mikel-Landa The XP Usage API seems to be the better option here than defining it per resource in the providers: https://docs.crossplane.io/v1.17/concepts/usages/

[Mikel-Landa]

@jeanduplessis I've got a couple of issues with the current implementation:

Kubernetes

Usages break the kubernetes principles of declarative definitions and eventual consistency.
You must tell crossplane the order to delete resources, which defeats the purpuse of k8s and if you don't do so, resources are stuck pending deletion with no hope of self-recovery.

I'm working with Azure and everything is nested here, currently I have over 50 usages for one environment (and I've tried deleting the env with no usages to see what get's stuck multiple times before creating that many).

Terraform

Relationships may not be all that clear (most are, but there are edge cases) and I feel is the responsability of the provider developer, just like in terraform, to decide relationships between objects.

Developer Experience

Even ignoring the first two issues, usages are very tedious to create and mantain, making the developer experience less than ideal