|
| 1 | +# Bucket Notifications |
| 2 | + |
| 3 | +## Bucket Notification Configuration |
| 4 | + |
| 5 | +Bucket's notifications can be configured with the s3api operation [put-bucket-notification-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/put-bucket-notification-configuration.html). |
| 6 | +Specify notifications under the "TopicConfigurations" field, which is an array of jsons, one for each notification. |
| 7 | +A notification json has these fields: |
| 8 | +- Id: Mandatory. A unique string identifying the notification configuration. |
| 9 | +- Events: Optional. An array of [events](https://docs.aws.amazon.com/AmazonS3/latest/userguide/notification-how-to-event-types-and-destinations.html) for which the notification is relevant. |
| 10 | + If not specified, the notification is relevant for all events. |
| 11 | +- TopicArn: The connection file (see below). (To specify a Kafka target topic, see "Kafka Connection Fields" below). |
| 12 | + |
| 13 | +Example for a bucket's notification configuration, in a file: |
| 14 | +{ |
| 15 | + "TopicConfigurations": [ |
| 16 | + { |
| 17 | + "Id": "created_from_s3op", |
| 18 | + "TopicArn": "secret-name/connect.json", |
| 19 | + "Events": [ |
| 20 | + "s3:ObjectCreated:*" |
| 21 | + ] |
| 22 | + } |
| 23 | + ] |
| 24 | +} |
| 25 | + |
| 26 | + |
| 27 | +## Connection File |
| 28 | +A connection file contains some fields that specify the target notification server. |
| 29 | +The connection file name is specified in TopicArn field of the [notification configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/put-bucket-notification-configuration.html) |
| 30 | + |
| 31 | +-In a containerized environment, the operator will mount the secrets as file in the core pod (see operator doc for more info). |
| 32 | +The mount path is `/etc/notif_connect/<secret-name>/<secret failename>`, and the notification reference the file by the `<secret-name>/<secret filename>` path in TopicArn field. |
| 33 | +For example, if seceret was created with: |
| 34 | +`kubectl create secret generic notif-secret --from_file connect.json` |
| 35 | +Then TopicArn should be `notif-secret/connect.json`. |
| 36 | + |
| 37 | +-In a non-containerized system, you must create the relevant file using the 'connections' CRUB cli. |
| 38 | +See the NC cli doc for more info. |
| 39 | +Connect file contains a single json with the fields specified below. |
| 40 | + |
| 41 | +### Common Connection Fields |
| 42 | +- name: A string identifying the connection (mandatory). |
| 43 | +- notification_protocol: One of: http, https, kafka (mandatory). |
| 44 | + |
| 45 | +### Http(s) Connection Fields |
| 46 | +- agent_request_object: Value is a JSON that is passed to to nodejs' http(s) agent (mandatory). |
| 47 | +Any field supported by nodejs' http(s) agent can be used, specifically 'host' and 'port'. |
| 48 | +A full list of options is [here](https://nodejs.org/docs/latest-v22.x/api/http.html#new-agentoptions). |
| 49 | + |
| 50 | +- request_options_object: Value is a JSON that is passed to nodejs' http(s) request (optional). |
| 51 | +Any field supported by nodejs' http(s) request option can be used, specifically: |
| 52 | +- 'path': used to specify the url path |
| 53 | +- 'auth': used for http simple auth. Value for 'auth' is of the syntax: <name>:<passowrd>. |
| 54 | + |
| 55 | +A full list of options is [here](https://nodejs.org/docs/latest-v22.x/api/http.html#httprequesturl-options-callback). |
| 56 | + |
| 57 | +### Kafka Connection Fields |
| 58 | +- metadata.broker.list: A CSV list of Kafka brokers (mandatory). |
| 59 | +- topic: A topic for the Kafka message (mandatory). |
| 60 | + |
| 61 | +## Event Types |
| 62 | +S3 spec lists several events and "sub events". |
| 63 | + |
| 64 | +The list of supported events are: |
| 65 | + |
| 66 | +- s3:ObjectCreated:* |
| 67 | +- s3:ObjectCreated:Put |
| 68 | +- s3:ObjectCreated:Post |
| 69 | +- s3:ObjectCreated:Copy |
| 70 | +- s3:ObjectCreated:CompleteMultipartUpload |
| 71 | +- s3:ObjectRemoved:* |
| 72 | +- s3:ObjectRemoved:Delete |
| 73 | +- s3:ObjectRemoved:DeleteMarkerCreated |
| 74 | +- s3:ObjectRestore:* |
| 75 | +- s3:ObjectRestore:Post |
| 76 | +- s3:ObjectRestore:Completed |
| 77 | +- s3:ObjectRestore:Delete |
| 78 | +- s3:ObjectTagging:* |
| 79 | +- s3:ObjectTagging:Put |
| 80 | +- s3:ObjectTagging:Delete |
| 81 | +- s3:LifecycleExpiration:* |
| 82 | +- s3:LifecycleExpiration:Delete |
| 83 | +- s3:LifecycleExpiration:DeleteMarkerCreated |
| 84 | + |
| 85 | +## Event Processing and Failure Handling |
| 86 | +Once NooBaa finds an event with a relevant notification configuration, the notification |
| 87 | +is written to a persistent file. |
| 88 | +Location of persistent files is determined by- |
| 89 | +- For containerized, the pvc specified in NooBaa Bucket Notification spec (see Operator docs for more info). |
| 90 | +- For NC, the env variable NOTIFICATION_LOG_DIR (see NC docs for more info). |
| 91 | + |
| 92 | +Files are processed by- |
| 93 | +- For containerized, files are contantly being processed in the background of the core pod. |
| 94 | +- For NC, files are processed by running manage_nsfs with 'notification' action. |
| 95 | + |
| 96 | +If a notification fails to be sent to the external server, it will be re-written to a persistent file (assuming the |
| 97 | +notification is still configured). |
| 98 | +Once this new file is processed, NooBaa will try to re-send the failed notification. |
0 commit comments