Support Knative eventing in `kn`

[maximilien]

I know there are at least two proposals in the works for supporting Knative eventing in the kn CLI. Proposing that this issue is used to have the initial discussions and when we reach agreements the necessary issues created to break down the features.

cc: @rhuss @daisy-ycguo @csantanapr

[rhuss]

@maximilien thanks for opening this issue !

I will have an initial proposal ready end of the day. It will some use cases that we see and has a suggestion how to deal with importer and channel type that are known at kn-build time (e.g. KafkaSource) and types that are not known and can be provided by users (e.g. a fictional TwitterSource). This will happen in a transparent way so that this difference is opaque to the user and all importers/channels are treated on the same level.

[daisy-ycguo]

Eventing WG is using this issue to track the discussion about UX and use cases.

[maximilien]

Thanks @rhuss for the update.

@daisy-ycguo the idea is to use here for the kn specific aspects. But glad to include the cross-link.

[rhuss]

@maximilien https://docs.google.com/document/d/1DpiSL2dUcYS2n7yXOIG5LJwyIC1lY9q_W8-56U1SvKM/edit?hl=en# has some relevant examples at the end of the document, which illustrates a potential usage pattern for kn (with a higher level of abstraction that we are currently using for managing servicing).

[sixolet]

Creating resources for particular eventing sources is an excellent example of where suggested-by-the-server plugins are likely to be a great fit for kn — installing the CRD for the eventing source also has a client plugin resource that you install to get the CLI for it.

[maximilien]

Adding another IBM colleague @komaldhull who has been thinking about Knative, Kn, and eventing.

I believe both @daisy-ycguo and Komal will be joining us to the WG call tonight (1:30a Beijing time) so I will glad to introduce them briefly to the rest of the team. Hangout soon. Cheers 🍻

[rhuss]

I believe both @daisy-ycguo and Komal will be joining us to the WG call tonight (1:30a Beijing time) so I will glad to introduce them briefly to the rest of the team. Hangout soon. Cheers 🍻

Wow, that's late (or very early :). ☕️ for the win :)

Yeah, sounds good. I'm a bit late with my proposal, and not sure whether there will be much time before to read it. So I think we should kickoff that discussion today, but discuss the various option in detail in the next week ?

[maximilien]

Yeah, sounds good. I'm a bit late with my proposal, and not sure whether there will be much time before to read it. So I think we should kickoff that discussion today, but discuss the various option in detail in the next week ?

Yup. We definitely want to collaborate. So, yup, let's use a few minutes for intro and tee up discussion for future.

I have two more IBM colleagues (cloud engineers) here from Beijing 🇨🇳 that I trying am recruiting to Knative 😀 so we'll have more to intro in future 🤞

Fun times a head 🎉

[rhuss]

Here's the draft of our proposal for a Kn eventing integration into kn:

https://docs.google.com/document/d/1T51o_sLUxjSKJq49zvTNQ0u8HlWwmK7fKnxPEnOZ2WI/edit?usp=sharing

I would be super happy for any feedback on this proposal which I did together with @matzew and whether its heading in the right direction or wether we are totally off.

The proposal also connects to the uses cases described in this document.

The three main themes are:

• Introducing the Integrator and Developer roles and how their use cases map to kn commands.
• How to extend importers and channels with custom types that are initially unknown to kn.
• How to help Developers with an opinionated way to connect their services to a given event topology.

'happy to discuss this proposal on Tuesday as well.

(Originally this proposal was written in asciidoc and the converted to Google docs. Happy to convert it back and check it into the repo in case its get accepted)

[rhuss]

It should be noted, that the section on "Sequences" is not complete and walkthrough examples at the end are still pending. Hope to be able to add it untitl the WG call.

[maximilien]

@daisy-ycguo @komaldhull see @rhuss's proposal on eventing ^^^^

Might be good to start comparing and contrasting with your proposal, which I would also share here in preparation for tomorrow's WG.

[komaldhull]

Here's my proposal: https://docs.google.com/document/d/1w1tEG3_JSRwXeSk00-_bzM4hVEFDK-NhBJGOk6jOtQE/edit?usp=sharing

(The primary difference is that I have triggers and subscriptions exposed explicitly as resources-- but regarding that, after reading Roland's proposal, I do agree that a single "connection" command would be better for kn.)