-
Notifications
You must be signed in to change notification settings - Fork 345
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kamelet CloudEvents set source
attribute to the string "source"
#3668
Comments
source
source
attribute to the string "source"
I had a look at the implementation and I need some more information about how to move forward. In order to set the context, a KameletBinding is an high level abstraction that is rendered to a number of Camel routes so assuming you have a from Twitter to Knative binding as in this case, like: apiVersion: camel.apache.org/v1alpha1
kind: KameletBinding
metadata:
name: twitter-to-channel
spec:
source: (1)
ref:
kind: Kamelet
apiVersion: camel.apache.org/v1alpha1
name: twitter-search-source
properties:
keywords: "foo,bar"
accessToken: "the-token-here"
sink: (2)
ref:
kind: InMemoryChannel
apiVersion: messaging.knative.dev/v1
name: tweets Then it gets roughly translated in something like: from("twitter-search:foo,bar?accessToken={{accessToken}}") //1
.routeId("source")
.to("direct:sink");
from("direct:sink") //2
.routeId("sink")
.to("knative:channel/tweets"); What the It could be possible to retrieve the original from uri to set the source field, however this pose some questions as the uri may contain information that are not needed but most important, placeholders and/or sensitive info which I think should not be exposed. Also what would be the best here for composing the source ? For this case, having something like It looks to me that this is another use case for #3501 @lance is it ok to have non unique sources ? i.e. if you create two from Twitter to Knative bindings for the same set of keywords but for different accounts. |
Thanks for this explanation.
It is too bad that the URI may contain sensitive info because IMO this is the proper value for a source attribute.
Per the spec, I believe the combination of the the
|
@lance it will take a while but we are working to improve support for cloud events, this is the start apache/camel-kamelets#1162 |
This issue has been automatically marked as stale due to 90 days of inactivity. |
Just following up here so that the issue doesn't get closed, and to provide what is my current workaround for this issue. When creating a Knative apiVersion: camel.apache.org/v1alpha1
kind: KameletBinding
metadata:
name: telegram-source-binding
spec:
source:
ref:
kind: Kamelet
apiVersion: camel.apache.org/v1alpha1
name: telegram-source
properties:
authorizationToken: API_TOKEN_HERE
steps:
- ref:
apiVersion: camel.apache.org/v1alpha1
kind: Kamelet
name: insert-header-action
properties:
name: CamelCloudEventSource
value: org.apache.camel.event.telegram
- ref:
apiVersion: camel.apache.org/v1alpha1
kind: Kamelet
name: insert-header-action
properties:
name: CamelCloudEventType
value: telegram.message
sink:
ref:
kind: Broker
apiVersion: eventing.knative.dev/v1
name: default This works fine, but it would be nice to have reasonable defaults so that the yaml can be as simple as possible. |
@christophd I think this would be now covered by https://github.com/apache/camel-kamelets/blob/4.2.x/kamelets/data-type-action.kamelet.yaml. Can you confirm? |
When using a Twitter search source kamelet (and I assume it's applicable to all kamelets), I have found that the CloudEvent headers, while adhering to the CE spec, don't necessarily adhere to the spirit. Specifically, with the
source
attribute, the value provided issource
. The spec specifies thesource
field is a URI reference. We could argue thatsource
is a relative URI, but it's definitely not the actual source of the event.It would be much nicer if the
source
attribute could be used to identify the event producer uniquely.The
type
attribute could also be improved. That value is currentlyorg.apache.camel.event
which is pretty good. It adheres to the CE spec recommendation.But really all we are getting with this value is the prefix. It would be great if, for example, the type could be something that would allow more finely grained filtering. E.g.
org.apache.camel.event.twitter.search
for a Twitter search kamelet, andorg.apache.camel.event.twitter.timeline
for a Twitter timeline kamelet.🙏
The text was updated successfully, but these errors were encountered: