Open Stack

-----Original Message-----
From: Sandy Walsh <sandy.walsh at RACKSPACE.COM>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Date: Thursday, July 10, 2014 at 9:31 AM
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [all] Treating notifications as a contract

>Ultimately this is the core problem. A breaking change in the
>notifications caused tests to fail in other systems. Should we be adding
>more tests or simply add version checking at the lower levels (like the
>first pass of RPC versioning did)?
>
>(more on this below)
>
>>  2. versioned notification payloads to protect consumers from breaking
>>     changes in payload format
>Yep, like RPC the biggies are:
>1. removal of fields from notifications
>2. change in semantics of a particular field
>3. addition of new fields (not a biggie)

The original implementation of the notification system was never intended
to be the *final* implementation. I think we all identified the need for
versioning several years ago. As for backwards compatibility, I think the
version field itself, in whatever form it takes, should be optional. If
not provided, it can be assumed the body of the notification is freeform.

Adding fields is easy. Removal of fields should only occur after we can
comfortably say that all services are only consuming the new field and
we¹ve left sufficient time for deprecating the old ones.

>>  
>>  3. external discoverability of which event types a service is emitting
>These questions can be saved for later, but ...
>
>Is the use-case that a downstream system can learn which queue to
>subscribe to programmatically?
>
>Is this a nice-to-have?
>
>Would / should this belong in a metadata service?

In some capacity, I think PubSubHubBub has a lot to offer here. The
publisher has to be able to provide a list of feeds it¹s authoritative
for, which I think is sufficient for discovery. I think PSHB itself is bit
heavy weight for what we need (and has some scaling problems) but I think
the concept itself is very useful for us.

>
>>  4. external discoverability of which event types a service is consuming
>
>Isn't this what the topic queues are for? Consumers should only
>subscribe to the topics they're interested in

I¹m not sure I understand the value of this one. A service consumes what
it consumes. If we¹ve versioned correctly, as mentioned above, why does it
matter?

>> If you're thinking that sounds like a substantial chunk of cross-project
>> work & co-ordination, you'd be right :)
>
>Perhaps notification schemas should be broken out into a separate
>repo(s)? That way we can test independent of the publishing system. For
>example, our notigen event simulator [5] could use it.
>
>These could just be dependent libraries/plugins to oslo.messaging.

+1