-----Original Message----- From: Sandy Walsh <sandy.wa...@rackspace.com> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: Thursday, July 10, 2014 at 9:31 AM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
