Open Stack

On Mon, Apr 06, 2015 at 01:17:20PM -0500, Matt Riedemann wrote:
> 
> 
> On 4/6/2015 9:46 AM, Chris Friesen wrote:
> >On 04/06/2015 07:56 AM, Ed Leafe wrote:
> >>On Apr 6, 2015, at 1:21 AM, Chris Friesen <chris.friesen at windriver.com>
> >>wrote:
> >>
> >>>>Please feel free to add a blueprint in Launchpad. I don't see this as
> >>>>needing a full spec, really. It shouldn't be more than a few lines of
> >>>>code to send a new notification message.
> >>>
> >>>Wouldn't a new notification message count as an API change?  Or are we
> >>>saying that it's such a small API change that any discussion can
> >>>happen in
> >>>the blueprint?
> >>
> >>I don't think that the notification system is the same as the API. It is
> >>something that you can subscribe to or not, and is distinct from the API.
> >
> >It's certainly not the same as the REST API.  I think an argument could
> >be made that the notification system is part of the API, where API is
> >defined more generally as "something that expresses a software component
> >in terms of its operations, inputs, outputs, and underlying types".
> >
> >If we don't exercise any control over the contents of the notifications
> >messages, that would make it difficult for consumers of the
> >notifications to do anything interesting with them.  At a minimum it
> >might make sense to do something like REST API microversions, with a
> >version number and a place to look up what changed with each version.
> 
> The events and their payloads are listed in the wiki here [1].
> 
> In the past people have added new notifications with just bug reports, I'm
> not sure a new spec is required for a host going into maintenance mode (as
> long as it's new and not changing something).

Yeah, in it's current state without real versioning on notifications I think
just adding it with a bug is fine. If nova actually had a versioning mechanism
and made stability guarantees on notifications it would be a different story.

> 
> And yes, we have to be careful about making changes to existing
> notifications (the event name or the payload) since we have to treat them
> like APIs, but (1) they aren't versioned today and (2) we don't have any
> kind of integration testing on the events that I'm aware of, unless it's
> through something like ceilometer trying to do something with them in a
> tempest scenario test, but I doubt that.

There are a couple of notification tests in tempest [2][3] but only 1 which uses
nova. But, this actually re-raises something which I brought up last summer
about how we need real versioning on notifications, and having real functional
testing of the notifications if we are going to rely on them and enable external
consumption. IMO, just testing it implicitly in tempest through ceilometer is
the wrong approach. It makes sense to have this kind of testing in tempest after
we have direct testing of notifications, but until that and real stability
guarantees are in place for notifications it makes testing it in tempest
problematic. (which just mirrors the experience of consumers of the
notifications)

We previously haven't blocked any of this testing in tempest, but the fact that
only 4 notification tests have been added of which 2 are skipped and the other 2
have been problematic at some point make me very hesitant about adding more
until we have the missing pieces in place.

> 
> [1] https://wiki.openstack.org/wiki/SystemUsageData
> 

-Matt Treinish

[2] http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/telemetry/test_telemetry_notification_api.py
[3] http://git.openstack.org/cgit/openstack/tempest/tree/tempest/scenario/test_swift_telemetry_middleware.py
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150406/6971c10b/attachment.pgp>