On 7/15/2014 3:51 AM, Mark McLoughlin wrote: > On Fri, 2014-07-11 at 10:04 +0100, Chris Dent wrote: >> On Fri, 11 Jul 2014, Lucas Alvares Gomes wrote: >> >>> The data format that Ironic will send was part of the spec proposed >>> and could have been reviewed. I think there's still time to change it >>> tho, if you have a better format talk to Haomeng which is the guys >>> responsible for that work in Ironic and see if he can change it (We >>> can put up a following patch to fix the spec with the new format as >>> well) . But we need to do this ASAP because we want to get it landed >>> in Ironic soon. >> It was only after doing the work that I realized how it might be an >> example for the sake of this discussion. As the architecure of >> Ceilometer currently exist there still needs to be some measure of >> custom code, even if the notifications are as I described them. >> >> However, if we want to take this opportunity to move some of the >> smarts from Ceilomer into the Ironic code then the paste that I created >> might be a guide to make it possible: >> >> http://paste.openstack.org/show/86071/ > So you're proposing that all payloads should contain something like: > > 'events': [ > # one or more dicts with something like > { > # some kind of identifier for the type of event > 'class': 'hardware.ipmi.temperature', > 'type': '#thing that indicates threshold, discrete, > cumulative', > 'id': 'DIMM GH VR Temp (0x3b)', > 'value': '26', > 'unit': 'C', > 'extra': { > ... > } > } > > i.e. a class, type, id, value, unit and a space to put additional metadata.
This looks like a particular schema for one event-type (let's say "foo.sample"). It's hard to extrapolate this one schema to a generic set of common metadata applicable to all events. Really the only common stuff we can agree on is the stuff already there: tenant, user, server, message_id, request_id, timestamp, event_type, etc. Side note on using notifications for sample data: 1. you should generate a proper notification when the rules of a sample change (limits, alarms, sources, etc) ... but no actual measurements. This would be something like a "ironic.alarm-rule-change" notification or something 2. you should generate a minimal event for the actual samples "CPU-xxx: 70%" that relates to the previous rule-changing notification. And do this on a queue something like "foo.sample". This way, we can keep important notifications in a priority queue and handle them accordingly (since they hold important data), but let the samples get routed across less-reliable transports (like UDP) via the RoutingNotifier. Also, send the samples one-at-a-time and let them either a) drop on the floor (udp) or b) let the aggregator roll them up into something smaller (sliding window, etc). Making these large notifications contain a list of samples means we had to store state somewhere on the server until transmission time. Ideally something we wouldn't want to rely on. > On the subject of "notifications as a contract", calling the additional > metadata field 'extra' suggests to me that there are no stability > promises being made about those fields. Was that intentional? > >> However on that however, if there's some chance that a large change could >> happen, it might be better to wait, I don't know. > Unlikely that a larger change will be made in Juno - take small window > of opportunity to rationalize Ironic's payload IMHO. > > Mark. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev