oscerd commented on issue #2303: URL: https://github.com/apache/camel-kamelets/issues/2303#issuecomment-5581974861
Correcting my previous comment — I wrote it without reading the 2024 thread above, which was careless, and it shows in two places. **What I got wrong.** I said "for Ceph the transport is whatever the operator configured, so there is no single wiring to capture". @yuvalif had already answered that: *"in case of ceph we are using kafka not sqs"*. Ceph RGW does support HTTP and AMQP, but the deployment being asked about uses Kafka, and that is a specific wiring, not an open-ended one. I also presented the `aws-s3-event-based-source` analogy as a finding when @oscerd had made exactly that point in the first reply, two years ago. **What that changes.** My "option 2" — a Ceph event-based source — was the weaker of the two options in my comment, on the grounds that it would be "kafka-source with a different name". That reasoning does not survive the correction. `aws-s3-event-based-source` is not "sqs-source with a different name" either: it consumes the queue, parses the S3 event, and optionally fetches the object that the event points at. A Ceph equivalent would do the same three things with Kafka in place of SQS. So by the catalog's own precedent the Kamelet is justified, and @yuvalif's point sharpens it — the AWS variant is locked to SQS, whereas a Kafka-backed one works against any Ceph deployment. **What stands.** The two things I checked still hold, and neither is affected by the thread: - there is no `camel-ceph` component; `ceph-source` / `ceph-sink` are `aws2-s3` with `uriEndpointOverride`, so the object-fetch half is already available - `camel-aws2-s3` exposes no notification-configuration operation, so *configuring* the notification stays outside Camel — which is consistent with @oscerd's position in this thread that the component will not grow Ceph-specific configuration That leaves @yuvalif's remark about *"extensions to the bucket notification configuration that you might want to expose"* as the one open question I cannot resolve from here: those extensions are set when creating the notification, which is the part that is not a Camel route. If they also appear **in the delivered event payload**, a Kamelet could surface them and that is worth knowing; if they are only configuration, the earlier answer in this thread applies. I would like to build the `ceph-event-based-source` — Kafka in, notification parsed, optional object fetch through the existing Ceph S3 path — unless you would rather it wait. @yuvalif, a sample of the notification JSON your deployment produces would make the parsing exact rather than assumed. Apologies for the noise of the previous comment. --- _Claude Code on behalf of Andrea Cosentino_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
