Open Stack

> Yeah, I'd really like to have a schema for Heat events so we can have a
> single event stream and repackage events for different consumption goals
> (metrics, notifications, programmatic interaction, etc).

Keystone and parts of Ceilometer use the CADF schema to build notification messages[1]. you can see example usage in ceilometermiddleware[2] but as an example, it basically builds a notification similar to:

 {
        'typeURI': 'http: //schemas.dmtf.org/cloud/audit/1.0/event',
        'eventTime': '2015-01-30T16: 38: 43.233621',
        'target': { # target of event
            'typeURI': 'service/storage/object',
            'id': 'account',
        },
        'observer': { 
            'id': 'target'
        },
        'eventType': 'activity',
        'measurements': [ # measurements if appplicable
            {
                'metric': {
                    'metricId': 'openstack: uuid',
                    'name': 'storage.objects.outgoing.bytes',
                    'unit': 'B'
                },
                'result': 28
            }
        ],
        'initiator': { # who is triggering event
            'typeURI': 'service/security/account/user',
            'project_id': None,
            'id': 'openstack: 288f6260-bf37-4737-a178-5038c84ba244'
        },
        'action': 'read',
        'outcome': 'success',
        'id': 'openstack: 69972bb6-14dd-46e4-bdaf-3148014363dc'
    }

a few of the fields are generated if not given. i just mention this because i've found it immensely easier as a consumer to work off a consistent format.


[1] http://docs.openstack.org/developer/pycadf/
[2] https://github.com/openstack/ceilometermiddleware/blob/master/ceilometermiddleware/swift.py#L198-L227

cheers,

gord