Description

This proposal is about extending the KReference resolver to support non-addressable objects (no status.address field). For those objects, we propose to delegate the reference resolution to an external service which upon receiving a KReference object replies with a resolved URI or an "not supported" error allow people to define a mapping between "Kind" and "URL-Template", where the URL-Template can use fields from the Object being referenced.

Use Case

The driving use case is this one: for instance, as a user I want to be able to trigger a batch job every day by having a PingSource CR targeting a batch job definition:

IMPORTANT NOTE: this is just an example! The source can be anything (Github, Kafka, you name it) and JobDefinitition can also be anything that is not Addressable.

apiVersion: my.batch.job/v1alpha1
kind: JobDefinition
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4 
---
apiVersion: sources.knative.dev/v1
kind: PingSource
metadata:
  name: trigger-job
spec:
  schedule: "@daily"  
  sink:
    ref:
      apiVersion: my.batch.job/v1alpha1
      kind: JobDefinition
      name: pi

Exit Criteria
Users are now able to reference non-addressable object

Experimental flag name: kreference-custom-resolvers

Experimental feature stages plan

Below the proposed plan for the feature stages (this list implicitly includes the requirements defined in the process)

• Alpha:
  • Extend URIFromObjectReference to support custom resolvers in knative/pkg
  • Add kreference-mapping experimental flag
  • Add a new configmap (kreference-mapping.yaml) to configure mappings between "Kind" and "URL-Template"
  • Implement kind -> URL mapping URI resolver
  • PingSource uses the new custom resolver
  • Track reference
  • All controllers relying on sink resolver uses the new custom resolver
  • User documentation
• Beta graduation as soon as 1 release after the inception
• Beta:
  • User documentation stabilization and improvements
  • More e2e tests
  • Add conformance tests
• Stable graduation as as soon as 2 releases after the Beta graduation
• Stable:
  • Add the requirement to the spec

Affected WG

• Eventing WG
• Networking WG