openstack/keystone
Code Issues Proposed changes

add 'project' notifications to docs

Browse Source 
In addition to adding a mention about 'project' notifications, I rewrote
a few bits of the notifications docs to make it easier to add new
resource types as we implement them (you only have to add them to the
list, rather than revising a bunch of disparate paragraphs).

blueprint notifications

Change-Id: I4792e5dd368d5404c252d6c7c8dc8813af7509d8
This commit is contained in:
Dolph Mathews
2013-08-30 07:28:54 -05:00
parent 372a06236a
commit d1e3496716
1 changed files with 37 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

64
doc/source/event_notifications.rst
View File

@@ -23,40 +23,50 @@ can use the data for billing, monitoring, or quota purposes. This document
describes the current inclusions and exclusions for Keystone usage
notifications.
Notifications for Create/Update/Delete Events
=============================================
Create/Delete/Update User
=========================
A notification is sent when a resource is successfully ``created``,
``updated``, or ``deleted``. The following resource types (where a
``<resource type>`` is always a singular noun) produce notifications:
One notification is sent when a user
is successfully created, deleted, or updated.
- ``user``
- ``project`` (i.e. "tenant")
The following message is sent when create user finishes::
The following message template is used to form a message when an operation on a
resource completes successfully::
{"event_type": "identity.user.created",
"message_id": "<message ID>",
"publisher_id": "identity.<hostname>",
"timestamp": "<timestamp>",
"priority": "INFO",
"payload":
{"resource_info": "<resource ID>"}}
{
"event_type": "identity.<resource type>.<operation>",
"message_id": "<message ID>",
"payload": {
"resource_info": "<resource ID>"
},
"priority": "INFO",
"publisher_id": "identity.<hostname>",
"timestamp": "<timestamp>"
}
Notifications for deletes and updates are similar to those for creates, with
``deleted`` or ``updated`` replacing ``created`` in the above notification.
If the operation fails, the notification won't be sent, and no special
error notification will be sent. Information about the error is handled
through normal exception paths.
Notifications for create, update and delete events are all similar to each
other, where either ``created``, ``updated`` or ``deleted`` is inserted as the
``<operation>`` in the above notification's ``event_type``.
If the operation fails, the notification won't be sent, and no special error
notification will be sent. Information about the error is handled through
normal exception paths.
Notification Example
====================
^^^^^^^^^^^^^^^^^^^^
This is an example of a notification sent for user creation::
This is an example of a notification sent for a newly created user::
{"event_type": "identity.user.created",
"message_id": "0156ee79-b35f-4cef-ac37-d4a85f231c69",
"publisher_id": "identity.host1234",
"timestamp": "2013-08-29 19:03:45.960280",
"priority": "INFO",
"payload":
{"resource_info": "671da331c47d4e29bb6ea1d270154ec3"}}
{
"event_type": "identity.user.created",
"message_id": "0156ee79-b35f-4cef-ac37-d4a85f231c69",
"payload": {
"resource_info": "671da331c47d4e29bb6ea1d270154ec3"
},
"priority": "INFO",
"publisher_id": "identity.host1234",
"timestamp": "2013-08-29 19:03:45.960280"
}