[Proposal] We should have sources.knative.dev

[n3wscott]

sources.eventing.knative.dev is too long and should not include eventing. I think we should move the resources to sources.knative.dev

Thoughts?

Update:

Here is my thinking, I am attempting to define the internal brands inside of Knative.

• Eventing brand is event based mesh-like interactions. Sources are not this.
• Messaging is point to point persistence delivery. Sources are also not this.
• Flows are routing. Sources do not do this.
• Sources are event producing resources.

So asking a user to use sources.eventing.knative.dev to me means you need to use eventing to make sources work, and it does not tell them it is ok to 1) use it independently; and 2) it plays with the other components in the Knative eco-system.

[matzew]

Yes, that makes sense to me, @n3wscott !

[vaikas]

sources.knative.dev it is.

[nachocano]

late to the party... but still... +1

[rgregg]

I’m against this change.

Sources.knative.dev has no clear connection with eventing and could be connected with source code, build, and/or FaaS scenarios in the future if the project moves that way.

I understand the desire to have a shorter string, but you need a connection to what kind of sources your talking about.

[mikehelmick]

@rgregg do you have other suggestions?

It is possible to use these sources without using eventing (or messaging) constructs.

I get what you're saying about reasons to not call it sources, but we didn't have anyone bring forward other options.

[rgregg]

From the context above, the problem was "string length". If that's the only problem we're trying to solve, I think we should punt completely and keep "sources.eventing.knative.dev".

The primary use case for sources is with eventing, is it not? I'm struggling to imagine advanced use cases where you wouldn't use them with scenarios focused on "eventing" even if you aren't using the whole eventing framework.

Should there be non-event based use cases for these sources, or would that belong in a different place so that we can keep these sources focused on a primary use-case and not over extend them?

[n3wscott]

Here is my thinking, I am attempting to define the internal brands inside of Knative.

• Eventing brand is event based mesh-like interactions. Sources are not this.
• Messaging is point to point persistence delivery. Sources are also not this.
• Flows are routing. Sources do not do this.
• Sources are event producing resources.

So asking a user to use sources.eventing.knative.dev to me means you need to use eventing to make sources work, and it does not tell them it is ok to 1) use it independently; and 2) it plays with the other components in the Knative eco-system.

I did not add this context to the description, but this is the thought process. I will add it now.

@rgregg

[rgregg]

I'm convinced.

[aslom]

What about src-eventing.knative.dev - what is length limit?

[n3wscott]

TODO:

• [] Update Eventing
• [] Update Eventing Contrib
• [] Update Docs

[grantr]

@n3wscott can this be closed?

[grantr]

All linked issues/PRs have been closed or merged. I'm calling this one done but please reopen if not.

/close

[knative-prow-robot]

@grantr: Closing this issue.

In response to this:

All linked issues/PRs have been closed or merged. I'm calling this one done but please reopen if not.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.