Match Backstage resources by Kubernetes label matching

[aliok]

In addition to the id matching, Backstage Kubernetes plugin also supports label matching. This means, there can be Kubernetes resources which are EventType consumers, and their link to Backstage is done using the label matching, instead of id matching.

To register Backstage relations for these components, we have 2 approaches:

1. Reverse matching

• Backend sends the labels of the consumer has when it collects the consumers
• Backstage finds out the components that have a label selector that can match the labels (reverse match)

2. 2nd call for fetching consumers

• Backend sends event types with no consumer information; Backstage receives the event types
• For each EventType received, Backstage iterates over all components with the annotation backstage.io/kubernetes-label-selector and sends a query to the backend
• Backend executes searches for the label selectors, finds out which components match
• Backend then finds out if any of these components are a consumer of an eventType.
• Backend returns the consumer relationship

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[aliok]

/remove-lifecycle stale

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[aliok]

/remove-lifecycle stale

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.