Open Stack

Thanks for the comments Jay.

Haven't acted on the comments yet, but I've just pushed an update with some simple validation capability. Fairly quick and dirty stuff, just wrapping the schema validation capability of python-jsonschema. You need jsonschema in your python env to run it.

Eddie
________________________________________
From: Sandy Walsh [sandy.walsh at RACKSPACE.COM]
Sent: Monday, January 19, 2015 7:53 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Notification Schemas ...

Thanks Jay, good feedback.

Comments inline ...

> ________________________________________
> From: Jay Pipes [jaypipes at gmail.com]
> Sent: Sunday, January 18, 2015 10:47 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] Notification Schemas ...
>
> On 01/18/2015 04:39 PM, Sandy Walsh wrote:
>
> > Eddie Sheffield has pulled together a strawman set of notification
> > schemas for Nova and Glance.
> >
> > https://github.com/StackTach/notification-schemas
>
> Some important things that I see are missing, so far... please let me
> know what your thoughts are regarding these.
>
> 1) There needs to be some method of listing the notification "codes". By
> "code", I mean "compute.instance_create.start", or possibly the CADF
> event codes, which I believe I recommended way back a-when the original
> ML thread started.

The "title" contains the event name
https://github.com/StackTach/notification-schemas/blob/master/nova/compute-instance-create-end.json#L4
but perhaps a wider CADF-like category would be good. And
we should have a close eye on ensuring we're capturing the broadest
CADF attributes now.

That said, CADF and schemas are complimentary. Once we have the
existing data mapped we should be able to determine which parts fit in
the CADF envelope directly and which parts need to go in the
"attachment" part (which will still need a separate schema definition). These
attachments could lead the way to changes to the core CADF spec. The
CADF team has stated they're receptive to that.

The notification driver can output the desired wire protocol.

> 2) Each notification message payload must contain a version in it.
> We need some ability to evolve the notification schemas over time,
> and a version in the payload is a pre-requisite for that.

Agreed. I suspect we'll be adding a common object to
https://github.com/StackTach/notification-schemas/blob/master/nova/objects.json
which will contain all that version stuff. Next round for sure.
This was just to capture what we have now.

> All the best,
> -jay
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev