Request for sources.knative.dev api feedback for v1alpha2 --> v1beta1

[n3wscott]

We are looking at moving the sources api to v1beta1.

This is a request for any feedback or changes needed for the following resources:

• ApiServerSource
• ContainerSource
• PingSource
• SinkBinding

[rhuss]

For the ApiServerSource there was a request to be able to filter on a resource's name with a trigger (not only the type). Not sure if this is easily possible already, but maybe the name could be added to a filterable attribute.

Also not sure if this affects the ApiServerSource resource schema at all though (or is just an implementation detail)

Otherwise, I'm not aware of any other feedback yet coming from client users (not sure also how much sources are actually used).

[rhuss]

Beside the name of a resource, copying over the labels of resources to filterable attributes would be nice, so that you emulate a label selector for trigger filters. Maybe another attribute like mode would be interesting to influence the data that gets copied over to filterable CE attributes ?

[n3wscott]

Thanks for the feedback @rhuss, we will take a look.

[lionelvillard]

For the PingSource, I have seen requests for supporting firing the event once on a specific date. OpenWhisk (among others) supports it: https://github.com/apache/openwhisk-package-alarms

[lionelvillard]

we also need to support timezone

[matzew]

we also need to support timezone

do we really need that on the pingsource ?

[matzew]

For the PingSource, I have seen requests for supporting firing the event once on a specific date. OpenWhisk (among others) supports it: https://github.com/apache/openwhisk-package-alarms

would that be a more specific use-case?

[lionelvillard]

timezone is needed when triggering an event at a particular time (e.g. Every Saturday at 23:45).

would that be a more specific use-case?

It seems that's a common use-case.

[nachocano]

@bryeung mentioned that @bharattkukreja might have some cycles to help with this.

As he is getting started in the project, I was thinking he can do simpler one(s) first, and then help more with the ones that need more changes, e.g., ApiServerSource, PingSource.

@n3wscott @lionelvillard how that sounds? ContainerSource, SinkBinding promotion to v1beta1?

[matzew]

Any update here, on the desired features?

[arzarif]

It would be great to be able to use ApiServerSources to extract information from remote clusters by providing a kubeconfig. Currently, an ApiServerSource can only interface the cluster it's running on.

I briefly talked to a couple of folks in the Slack channel and the idea of using a binding (something like the GithubBinding) to implement this came up. @mattmoor, @antoineco

[antoineco]

I think the KubeconfigBinding would be a nice addition to the existing source indeed.

It doesn't have to influence the graduation to beta though. The Binding can be implemented regardless of the API version, since it applies to the Pods created by sources, and not to the source objects themselves.

[lionelvillard]

Today, bindings only works with PodSpecable and APIServerSource is not. The APIServerSource implementation might use under the cover a PodSpecable per source or one for all in the same service account, but this is not available to the binding.

[capri-xiyue]

Beside the name of a resource, copying over the labels of resources to filterable attributes would be nice, so that you emulate a label selector for trigger filters. Maybe another attribute like mode would be interesting to influence the data that gets copied over to filterable CE attributes ?

the changes seems to be data plane wise
I will start with the move to v1beta1 first, and in case we need additional fields, we can always add them.
Are you folks ok with this? @nachocano @lionelvillard

[nachocano]

the move to v1beta1 first, and in case we need a

I'm fine with that. I think @rhuss suggestions can be handled without changing the API, is just a matter of creating a CE with more extension attributes.
Not entirely sure about the change of specifying a kubeconfig. But I think if we need to change the API for that, it will be an additive change and it should be fine.

So, I'm fine if you start with the move.
Let's hear from @lionelvillard

[lionelvillard]

I agree with @nachocano. It's all additive changes so we are fine.

[capri-xiyue]

I created a new issue to discuss the new feature requests for ApiSeverSource
#3675

[nachocano]

Created #3785 to track the addition of kubeconfig to ApiServerSource.
Thanks everyone who provided feedback. I think we can close this issue, as we have been addressing the comments in different issues/PRs. If you think otherwise, please feel free to reopen and we can further discuss it.