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

Reply via email to