Discussion: Sink Mappings revisited

[rhuss]

Currently, we have a set of fixed mappings for the --sink option of sources and triggers:

• broker: for specifying a broker
• service: & svc: for specifying a Knative service
• http: and https: for direct URL
• no prefix: Knative service

We can also add new mapping in the configuration file ~/.config/kn/config.yaml with

eventing:
  sink-mappings:
  - prefix: k8service
    resource: services
    group: core
    version: v1

However, I think this is not optimal:

• Knative service spec occupies too many "slots" (no prefix, svc:, service:)
• A K8s Service which is a perfectly valid target can not easily be specified, there is no good prefix available anymore

The question is also how many mapping we would like to add to kn as builtin mappings.
There are two possible ways:

• Intersection: Only restrict to addressable Knative entities (services, broker, channels)
• Union: Also allow entities from the underlying platform, like Kubernetes or CloudRun. Prominent example here is a Kubernetes service, but one could imagine also other mappings.

My suggestion is going for the latter approach and changing the built-in mappings to:

• Default is still a Knative service (i.e. can be specified without prefix)
• With prefix, only ksvc: is support for a Knative service
• svc: is used to map to a Kubernetes service
• More prefix could be added, even when they are targeting objects that are not covered by the Knative spec.

Note that this can't be easily achieved in a backwards-compatible way. Still, I believe we should make adjustments here (also considering that we also stated that the eventing support in kn was experimental).

What are your opinion on this topic ?

[navidshaikh]

For knative default addressable prefixes, we hard-code their GVKs as per the respective supported APIs by kn, this makes sure that when a prefix is given it'd work with connected cluster.

If we go with Union approach, we'd need to hard-code the respective GVKs.
This should be fine as long as the addressable in underlying platforms are stable enough (in v1 APIs).
Neverthless, the inbuilt prefix set should be small and experimental prefixes should go to the kn config. We can add Kubernetes service prefix now, and see if there are more requests?

+1 for making clear distinction between k8s service (svc) and knative service (ksvc).

Lets also discuss this in next working group call.

[navidshaikh]

/assign

Summarizing the discussion from WG call:

• Only knative resources to be mapped with default prefixes.
• ksvc prefix or no prefix means knative service.
• Free svc and service prefixes.