Just a thought - this sounds like systems such as Google protocol buffer are for, where multiple versions of structured data is serialized/deserialized. Thanks,
Yun On Wed, Oct 10, 2012 at 3:27 AM, Day, Phil <philip....@hp.com> wrote: > Hi All, > > I guess I may have mis-stated the problem a tad in talking about version > numbering. The notification system is an outbound interface, and my interest > is in being able to write consumers with some guarantee that they won't be > broken as the notification message format evolves. > > Having a version number gives the client a way to know that it may now be > broken, but that's not really the same as having an interface with some > degree of guaranteed compatibility, > > Phil > > -----Original Message----- > From: openstack-bounces+philip.day=hp....@lists.launchpad.net > [mailto:openstack-bounces+philip.day=hp....@lists.launchpad.net] On Behalf Of > David Ripton > Sent: 09 October 2012 20:59 > To: openstack@lists.launchpad.net > Subject: Re: [Openstack] Versioning for notification messages > > On 10/09/2012 01:07 PM, Day, Phil wrote: > >> What do people think about adding a version number to the notification >> systems, so that consumers of notification messages are protected to >> some extent from changes in the message contents ? >> >> For example, would it be enough to add a version number to the >> messages - or should we have the version number as part of the topic >> itself (so that the notification system can provide both a 1.0 and 1.1 >> feed), etc ? > > Putting a version number in the messages is easy, and should work fine. > Of course it only really helps if someone writes clients that can deal with > multiple versions, or at least give helpful error messages when they get an > unexpected version. > > I think using separate topics for each version would be inefficient and > error-prone. > > Inefficient because you'd have to send out multiples of each message, some of > which would probably never be read. Obviously, if you're sending out N > copies of each message then you expect only 1/N the queue performance. > Worse, if you're sending out N copies of each message but only 1 of them is > being consumed, your queue server is using a lot more memory than it needs > to, to hold onto old messages that nobody needs. > (If you properly configure a high-water mark or timeout, then the old > messages will eventually be thrown away. If you don't, then your queue > server will eventually consume way too much memory and start swapping, your > cloud will break, and someone will get paged at 2 a.m.) > > Error-prone because someone would end up reusing the notification queue code > for less idempotent/safe uses of queues, like internal API calls. > And then client A would pick up the message from topic_v1, and client B would > pick up the same message from topic_v2, and they'd both perform the same API > operation, resulting in wasted resources in the best case and data corruption > in the worst case. > > -- > David Ripton Red Hat drip...@redhat.com > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp