What problem are you facing?

Many cloud provider external resources are associated with a non-deterministic ID/external-name. To deal with that, Crossplane providers rely on the crossplane.io/external-name annotation for discovering existing external resources that a managed resource controls.

It's not unusual for Crossplane users to set deletionPolicy to Orphan on production environments to prevent accidental deletions of external-resources in the event of human error or catastrophic failure in Kubernetes clusters requiring re-creation of all resources.

During such events, the MR gets re-created without the annotation, and one of these scenarios follow:

1. The MR breaks and never syncs, because it identifies the resource you're attempting to manage already exists, and it does not get imported automatically. Human intervention is required.
2. The MR results in the creation of a different resource, effectively duplicating everything, and the provider is now managing a resource which might not even be at use. In this scenario, the failure to import the existing resource is not reported, and it's marked as healthy (even though the original resource is now orphaned and unmanaged). Not only requires manual intervention, but might go unnoticed until other things start to break.

These problems are aggravated when compositions are used, as it makes it all more complex. For example, imagine a composition that manages DNS hosted zones. As well as creating the zone itself, it might also create NS records on the parent zone, to delegate authority to it.

Within the dropdown you'll find a concrete example of a real scenario we faced.

flowchart TD
 subgraph subgraph_aws["AWS"]
        hosted_zone(["Hosted Zone zone1 (foo.bar.baz)"])
        ns_record(["NS Record (on zone bar.baz, points to zone1)"])
  end
    mr_zone["Zone Managed Resource (external-name zone1)"]
    mr_record["Record Managed Resource"]
    xr["XR"] --> mr_zone & mr_record
    mr_zone --> hosted_zone
    mr_record --> ns_record

flowchart TD
 subgraph subgraph_aws["AWS"]
        hosted_zone(["Hosted Zone zone1 (foo.bar.baz)"])
        ns_record(["NS Record (on zone bar.baz, points to zone1)"])
  end

flowchart TD
 subgraph subgraph_aws["AWS"]
        hosted_zone(["Hosted Zone zone1 (foo.bar.baz)"])
        duplicated_zone(["Hosted Zone zone2 (foo.bar.baz)"])
        ns_record(["NS Record (on zone bar.baz, points to zone1)"])
  end
    mr_zone["Zone Managed Resource (external-name zone2)"]
    mr_record["Record Managed Resource"]
    xr["XR"] --> mr_zone & mr_record
    mr_zone --> duplicated_zone
    mr_record --> ns_record

How could Upjet help solve your problem?

Upjet could ensure that a tag with the external-name value is inserted into the external resource, along with crossplane-kind and crossplane-name tags it already currently inserts.

This would allow for importing mechanisms to filter existing resources using tags, then setting the external-name annotation on the managed resource if it finds the external-name tag set on it.

Proof of Concept

To deal exactly with the problem I mentioned we wrote a composition function that uses AWS' Resource Groups Tagging API to filter any AWS resource based on the tag Crossplane/Upjet already currently populates (crossplane-kind, crossplane-name).

https://github.com/gympass/function-aws-importer

The nice thing about this tagging API is that you can make the same API calls regardless of the exact type of the external resource, as long as it supports tags (most resources do). It works for Route53 Hosted Zones, EC2 Security Groups, etc.

It currently requires composition authors to ensure the external-name tag is there themselves, which leads to longer reconciliations, weird corner cases, and overall non-ideal user experience. If Upjet ensured this tag was there itself, we could avoid all of this and make the function itself self-contained.

To have a better idea of how this would work on Upjet, we deployed a fork with the following change: a6c0bc9

This is not necessarily the best way to implement this, but it proves the concept. We've been using this fork along with our function in our development environment with no failures to report so far.

Future

In the future, if this concept proves to be robust, Upjet could even use this tag to assemble the tfstate it produces on observe operations, making the function above useless by incorporating its functionality entirely. One step at a time though :-)