CLI: Add support for EventType v1beta2 about client HOT 6 CLOSED

@matzew @pierDipi @rhuss I was looking at switching to v1beta2 support and kn eventtype create flags. And I was wondering.

There are 2 paths here:

• Single --reference flag, that would parse the input for various format:

--reference "broker:<name>"
--reference "broker:<name>:<namespace>"
--reference "channel:<name>:<namespace>"

# fully qualified GVK
--reference "special.eventing.dev/v1beta3:Channel:<name>"
--reference "special.eventing.dev/v1beta3:Channel:<name>:<namespace>"

• Multiple flags for well know and popular references (broker, channel, kafka-broker) and single --reference for complete GVK. We already have --broker flag, that I'd like to keep for backward compatibility and convenience of use. Hence the idea with other well known flags.

The issue with this approach we faced in the past is that we will have opinionated defaults, but there's N+ other brokers out there. And we need to fiddle the popularity contest. :)

--broker "<name>"
--channel "<name>"
--broker-kafka "<name>"

# Only accepts qualified GVK
--reference "special.eventing.dev/v1beta3:Channel:<name>"
--reference "special.eventing.dev/v1beta3:Channel:<name>:<namespace>"

from client.

I'd go single

from client.

I think it should be aligned with the syntax options that we have for --sink, i.e. allowing shortcuts and full qualified entries. Algo would be:

• Split on :
• Check for a well-known shortcut (that should not have any . included)
• If found, take the latest version of the GVK as known, when kn was compiled (we could list these version in the help message where we should also list all available prefixes
• If not found, take the part as a full GVK (and split on /). So, I would use something like special.eventing.dev/channel/v1beta3 instead of another : (so that it's clear that the first part of that expression specifies the reference type, either in shortcut form or in full form.

from client.

Perhaps also add support for reference field (and deprecation warnings for broker field).
But that can be a separate issue

from client.

This's done in PR #1831, and released in Knative v1.11.0.

/close

from client.

@dsimansk: Closing this issue.

from client.