You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 ?
The text was updated successfully, but these errors were encountered:
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.
Currently, we have a set of fixed mappings for the
--sink
option of sources and triggers:broker:
for specifying a brokerservice:
&svc:
for specifying a Knative servicehttp:
andhttps:
for direct URLWe can also add new mapping in the configuration file
~/.config/kn/config.yaml
withHowever, I think this is not optimal:
svc:
,service:
)The question is also how many mapping we would like to add to
kn
as builtin mappings.There are two possible ways:
My suggestion is going for the latter approach and changing the built-in mappings to:
ksvc:
is support for a Knative servicesvc:
is used to map to a Kubernetes serviceNote 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 ?
The text was updated successfully, but these errors were encountered: