feat: allow setting custom parents via metadata (Alpha) #5082 #20908
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I took a stab at #5082 and took a slightly different approach. Instead of users specifying the parent/child relationship in config, we could allow setting it in the metadata.
This change allows users to define a parent/child relationship for resources where this cannot be inferred from the ownerRef values. The child resource might be a Cluster-scoped CR and the parent might be a namespaced CRD.
The API is straightforward and boils down to setting annotations that define the parent, i.e:
If a custom parent is defined, we take it over the ownerRef values.
This allows us to display a more ordered resource tree. Some concrete examples include Istio Operator and Crossplane resources (relationship between Claims and Composite Resources).
In the screenshots, you can see that it brings order to the resource tree of Istio Operator and draws the relationship between Crossplane Claim and Crossplane XR.
This is an early implementation and I would appreciate feedback on this approach and pointers on how to make it better. Thanks!
Updates #5082
Checklist: