openstack team mailing list archive

[Diego Parrilla Santamaría <diego.parrilla.santamaria@xxxxxxxxx>]

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.parrilla@xxxxxxxxxxxx** | +34 649 94 43 29 |
skype:diegoparrilla*
* <http://www.stackops.com/>
*

*




On Wed, Oct 10, 2012 at 12:02 PM, Day, Phil <philip.day@xxxxxx> 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.santamaria@xxxxxxxxx]
> *Sent:* 10 October 2012 09:18
> *To:* Day, Phil
> *Cc:* David Ripton; openstack@xxxxxxxxxxxxxxxxxxx
>
> *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.parrilla@xxxxxxxxxxxx | +34 649 94 43 29| skype:diegoparrilla
> *
> * <http://www.stackops.com/>****
>
> **
>
> ** **
>
>
>
> ****
>
> On Wed, Oct 10, 2012 at 9:27 AM, Day, Phil <philip.day@xxxxxx> 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.com@xxxxxxxxxxxxxxxxxxx [mailto:
> openstack-bounces+philip.day=hp.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> David Ripton
> Sent: 09 October 2012 20:59
> To: openstack@xxxxxxxxxxxxxxxxxxx
> 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   dripton@xxxxxxxxxx
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp****
>
> ** **
>