Hi Yuval,

We're using pubsub!

We opted for pubsub over bucket notifications as the pull mode fits well with 
our requirements.

1) We want to be able to guarantee that our client (the external server) has 
received and processed each event. My initial understanding of bucket 
notifications was that they weren't stored on ceph at all, and were simply 
broadcast and then forgotten. Actually I see that the docs state the 
notification will be retried until acked [3]. Is that guaranteed? Will ceph 
ultimately give up and drop an event? Is there a way of seeing how many events 
have been unacked / dropped?

2) Being able to pull a list of missed events back, rather than receiving them 
one at a time, allows our client to cut down on processing. As an example, if 
the same object is updated 10 times, pubsub catchup list will list 10 events 
for the same object, and the client can recognise this and only needs to 
process the object once and ack all 10 events.  The bucket notification model 
suggests we will have to process each event in turn. There are possibly ways we 
can work around this though (e.g. queue incoming bucket notifications on the 
client and process them in batches).

We've had a number of issues with pubsub and still aren't confident in its 
behaviour. Your post suggests its not well used, which might imply it has less 
field hardening that bucket notifications. If so, it sounds like it might be 
better for us both if we switched to using the bucket notifications method 
instead. It'd be good to get your thoughts on how we could satisfy two 
requirements above.

If pubsub is likely to be deprecated, we'll need to start moving fast. What's 
the latest thinking on this?

Cheers,

Dave

[3] 
https://docs.ceph.com/en/latest/radosgw/notifications/#notification-reliability

- 



-----Original Message-----
From: Yuval Lifshitz <ylifs...@redhat.com> 
Sent: 05 November 2020 06:57
To: ceph-users <ceph-users@ceph.io>
Subject: [ceph-users] RGW pubsub deprecation

NOTE: Message is from an external sender

Dear Community,
Since Nautilus, we have 2 mechanisms for notifying 3rd parties on changes in 
buckets and objects: "bucket notifications" [1] and "pubsub" [2].

In "bucket notifications" (="push mode") the events are sent from the RGW to an 
external entity (kafka, rabbitmq etc.), while in "pubsub" (="pull
mode") the events are synched with a special zone, where they are stored and 
could be later fetched by an external app.

>From communications that I've seen so far, users preferred to use "bucket 
>notifications" over "pubsub". Since supporting both modes has maintenance 
>overhead, I was considering deprecating "pubsub".
However, before doing that I would like to see what the community has to say!

So, if you are currently using pubsub, or plan to use it, as "pull mode"
fits your usecase better than "push mode" please chime in.

Yuval

[1] 
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2Fradosgw%2Fnotifications%2F&amp;data=04%7C01%7Cdavid.piper%40metaswitch.com%7C01afaedcb924464d82a408d8815821e0%7C9d9e56ebf6134ddbb27bbfcdf14b2cdb%7C1%7C0%7C637401562833936026%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=mSP8%2FrcB%2FRLPvpxD099BMzGiQzmwlitRpACN%2F85zyxc%3D&amp;reserved=0
[2] 
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.ceph.com%2Fen%2Flatest%2Fradosgw%2Fpubsub-module%2F&amp;data=04%7C01%7Cdavid.piper%40metaswitch.com%7C01afaedcb924464d82a408d8815821e0%7C9d9e56ebf6134ddbb27bbfcdf14b2cdb%7C1%7C0%7C637401562833936026%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=%2F4TYjlde8cekotkGKsTxl4dUroURq73CrcZsbdTuA7g%3D&amp;reserved=0
_______________________________________________
ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to 
ceph-users-le...@ceph.io
_______________________________________________
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io

Reply via email to