Open Stack

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 at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev