oscerd commented on issue #2303:
URL:
https://github.com/apache/camel-kamelets/issues/2303#issuecomment-5581113902
Looked into what this would actually take. The short version: the consuming
half already works today by composition, and the part that does not exist is
not a Camel route at all.
## There is no Ceph component to extend
`ceph-source` and `ceph-sink` are not backed by a `camel-ceph` component —
there is none in the catalog. They are `aws2-s3` pointed at the RGW endpoint
through Ceph's S3-compatible API:
```yaml
dependencies:
- "camel:aws2-s3"
template:
from:
uri: "aws2-s3:{{bucketName}}"
parameters:
uriEndpointOverride: "{{cephUrl}}"
overrideEndpoint: "true"
```
So "add bucket notifications to the Ceph Kamelets" has no component-level
hook to hang off. It splits into two quite different problems.
## Receiving notifications: already possible
Ceph RGW **pushes** bucket notifications to a configured endpoint — HTTP,
AMQP 0.9.1/1.0, or Kafka. Camel does not poll for them, it receives them, and
the catalog already has a source for each of those transports:
```
http-source webhook-source kafka-source jms-amqp-10-source
```
So the event-driven pipeline the issue asks for — "a notification based
mechanism instead of polling" — is available now by pointing Ceph at, say, a
Kafka topic and binding `kafka-source`. The payload is S3-event shaped JSON, so
it can be filtered and routed with the existing action Kamelets.
That is worth stating plainly, because it means nobody is blocked.
## Configuring notifications: not a route
The remaining piece — "configuring the notifications" — is an S3
`PutBucketNotificationConfiguration` call against the bucket. That is
administration, done once, not per-message, and `camel-aws2-s3` does not expose
it. Its full operation list is:
```
copyObject, listObjects, deleteObject, deleteObjects, deleteBucket,
listBuckets,
getObject, getObjectRange, createDownloadLink, createUploadLink, headBucket,
headObject, restoreObject, getObjectTagging, putObjectTagging,
deleteObjectTagging,
getObjectAcl, putObjectAcl, createBucket, getBucketTagging, putBucketTagging,
deleteBucketTagging, getBucketVersioning, putBucketVersioning,
getBucketPolicy,
putBucketPolicy, deleteBucketPolicy
```
No notification operation among them. Adding one would be a change to
`camel-aws2-s3` in `apache/camel`, and even then, wrapping a one-off admin call
in a Kamelet is a poor fit — Kamelets are route templates, and this is closer
to `aws cli` or Terraform territory.
## What could reasonably be added here
If the goal is to make the composition obvious rather than to invent a
component:
1. **A documented Pipe example** showing Ceph notifications landing on Kafka
or an HTTP endpoint and being consumed — nothing new in the catalog, but it
removes the discovery problem, which reads like the real complaint.
2. **A `ceph-notification-source`** that is a thin wrapper over one
transport with Ceph-shaped defaults. Honest question whether that earns its
place: it would be `kafka-source` with a different name, and the catalog
already resists that kind of aliasing.
The comparison with `aws-s3-event-based-source` is instructive — that one
exists because AWS routes events through SQS and there is a specific,
non-obvious wiring worth encapsulating. For Ceph the transport is whatever the
operator configured, so there is no single wiring to capture.
Leaving this open for a maintainer decision rather than closing it, since
option 1 is cheap and might be exactly what was wanted. Happy to write that
example up if you think it is worth having.
---
_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]
