You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Crossplane and its providers use a lot of references between custom resources. In some cases these are "typed" references, including group, version, and kind (GVK) information:
Historically we've used untyped references in cases where the types could be "filled in" by the controller. Cross-resource-references are one example of this - a "Subnet" managed resource controller always knows that a vpcIdRef field will be to a VPC so it doesn't need the type information at the API level (it's baked in at the code level). We've used typed references when the code didn't know what type would be referenced - typically when a reference could be to more than one type of resource. An example of this latter case is an XR referencing its composed resources.
The challenge with "untyped" references is that systems that consume Crossplane APIs don't have access to the information baked in at the code level. A web console for example probably doesn't actually know what a "Subnet" managed resource actually is and thus has no way of knowing what type its "vpcIdRef" field references. crossplane/crossplane#2255 is another example of this - it blocks systems like xgql being able resolve untyped references per upbound/xgql#37.
How could Crossplane help solve your problem?
I believe we should standardize on typed references everywhere.
The text was updated successfully, but these errors were encountered:
Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as stale because it has had no activity in the last 90 days. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with/fresh will mark this issue as not stale.
What problem are you facing?
Crossplane and its providers use a lot of references between custom resources. In some cases these are "typed" references, including group, version, and kind (GVK) information:
In other cases they are "untyped", for example:
Historically we've used untyped references in cases where the types could be "filled in" by the controller. Cross-resource-references are one example of this - a "Subnet" managed resource controller always knows that a
vpcIdRef
field will be to a VPC so it doesn't need the type information at the API level (it's baked in at the code level). We've used typed references when the code didn't know what type would be referenced - typically when a reference could be to more than one type of resource. An example of this latter case is an XR referencing its composed resources.The challenge with "untyped" references is that systems that consume Crossplane APIs don't have access to the information baked in at the code level. A web console for example probably doesn't actually know what a "Subnet" managed resource actually is and thus has no way of knowing what type its "vpcIdRef" field references. crossplane/crossplane#2255 is another example of this - it blocks systems like xgql being able resolve untyped references per upbound/xgql#37.
How could Crossplane help solve your problem?
I believe we should standardize on typed references everywhere.
The text was updated successfully, but these errors were encountered: