If you are proposing a new interface to the existing notification system that could be stable enough to 'survive' multiple versions, then I agree. The trade-off is we will loose information of the payload, unless somebody out there have a magic solution for this (and probably the version number is part of the recipe). But I guess we need this interface. There was something on the table 2 or 3 summits ago but the notification system did not evolve a lot (something that surprises me because from the business perspective Activity auditing is a must-be feature of any IaaS platform).
Talking about ceilometer, I think mixing notifications (activity) and usage (metrics) is not a good idea. I know people in the community disagree, but they are different things. -- Diego Parrilla <http://www.stackops.com/>*CEO* *www.stackops.com | * diego.parri...@stackops.com** | +34 649 94 43 29 | skype:diegoparrilla* * <http://www.stackops.com/> * * On Wed, Oct 10, 2012 at 12:02 PM, Day, Phil <philip....@hp.com> wrote: > Whilst a version number would allow a consumer to detect that something > has changed, it doesn’t really help in providing any kind of backward > compatibility.**** > > Consider the following scenario: There are a bunch of systems external to > Nova developed to consume notification messages, and someone introduces a > change to the notification system that changes the message content. They > do the right thing in updating the version number, but all of those > external systems now need to change as well. The new version number lets > them fail explicitly, but it could still have a significant impact on a > production system.**** > > ** ** > > Where I’d like to get to make the notification system a formal external > interface, that has the same degree of stability, version control, and > rigor around changes that the inbound API has. **** > > ** ** > > I would guess that Ceilometer will have some requirement around this ?**** > > ** ** > > Phil**** > > ** ** > > *From:* Diego Parrilla Santamaría [mailto: > diego.parrilla.santama...@gmail.com] > *Sent:* 10 October 2012 09:18 > *To:* Day, Phil > *Cc:* David Ripton; openstack@lists.launchpad.net > > *Subject:* Re: [Openstack] Versioning for notification messages**** > > ** ** > > If we want to have a notification system that could handle messages with > different payloads and different versions, we have two options: > > 1) detect the version of the payload in the notification message > 2) add a version number in the notification message > > Option 1 sounds to me like something hard to maintain. Option 2 seems to > be correct way to do it in the long term. > > +1 for a version number in the notification message > > Cheers > Diego > -- **** > > Diego Parrilla > *CEO* > *www.stackops.com | * diego.parri...@stackops.com | +34 649 94 43 29| > skype:diegoparrilla > * > * <http://www.stackops.com/>**** > > ** > > ** ** > > > > **** > > On Wed, Oct 10, 2012 at 9: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
