[openstack-dev] [all] Treating notifications as a contract
Mark McLoughlin
markmc at redhat.com
Tue Jul 15 06:47:38 UTC 2014
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.
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.
More information about the OpenStack-dev
mailing list