Support for Resource relations in schema generation

[nexus49]

Context

It would be very helpful to leverage the power of graphql to be able to traverse relationships in queries and subscriptions.

Tasks/Requirements

• Adjust generator and gateway for relationships
• Add the ability to the gateway to open multiple watches in case of a watch for a singe resource that has relationships.
  • the gateway needs to watch the requested resource plus each resource it has a relationship to.
  • the gateway should only open such watches if the fields were requested
• Relations should only be expanded if the fields are requested by the query
• Add Convention that resources have to follow so that the gateway supports the relationship (TBD convention needs to be decided upon, but lets assume below convention to start the work)

<kind>Ref:
  kind: <abc>  # kind is optional, should be provided if kind conflicts are possible, otherwise inferred from the `<kind>Ref` patttern
  apiGroup: <abc> # apiGroup is optional, should be provided if kind conflicts are possible
  name: <abc>
  namespace: <abc>

• The resulting action is that the listener adjusts the schema generation and adds a property linking to the referenced type.
• The resulting action is that the gateway retrieves the additional kubernetes objects and constructs the response object

Example Query that should be possible after the change:

{ 
  rbac_authorization_k8s_io {
    ClusterRoleBindings {
      roleRef {
        apiGroup
        name
        kind
        role {
          rules {
          verbs
        }
      }
    }
  }
}

Out of scope

• Only Queries no support for Subscriptions
• Only one level of Releation a-b-c relations are not supported for now
• Only single item Queries, not supported for lists for now

[vertex451]

Lets discuss the relations.

1. Are those examples valid?

• Deployment -> ReplicaSet -> Pod (via ownerReferences)
• Pod -> ServiceAccount
• ServiceAccount -> Token
• Volume -> PVC
• HPA → Deployment (via selector)
• Service -> Pod (via selector)

2. Do you have something in mind I should start from, or I can choose by my own?
3. Do we want a query where we can get a Deployment and its related Tokens (Deployment -> ReplicaSet -> Pod -> ServiceAccount -> Token)

[tobias-oetzel]

So for now i guess the

<kind>Ref:
  kind: <abc>  # kind is optional, should be provided if kind conficts are possible
  groupVersion: <abc> # groupVersion is optional, should be provided if kind conficts are possible
  name: <abc>
  namespace: <abc>

is more important than the native objects.
Further down the line, the native relations would be cool, but for our usecase the CRDs are the main focus.

I like the idea to generally be able to work with owner references, but its also not prio 1 for this i guess. Maybe we can split the aspects in separate issues.
So keep this one for the proposal with the ref, if defined as above.

[vertex451]

I can implement resource KindRef for any resource, that follows that convention, so it will support both CRDs and Built-in resources.
Ignoring other type or relations for now(ownerReferences, labels, etc)

[vertex451]

In ClusterRoleBinding we have k8s native field

roleRef {
  name
  kind
  apiGroup
}	

And with the task description we have also Ref which will misslead in case of role binded to clusterRoleBinding.

I already implemented Relation field that holds our custom field set.

Let me know if you want me to follow the Ref naming