[nova] What to do with the legacy notification interface?

Balázs Gibizer balazs.gibizer at ericsson.com
Fri Dec 7 08:48:44 UTC 2018



On Thu, Dec 6, 2018 at 6:35 PM, Matt Riedemann <mriedemos at gmail.com> 
wrote:
> On 12/6/2018 10:41 AM, Balázs Gibizer wrote:
>> Hi,
>> 
>> Last decision from the Denver PTG [1] was to
>> * finish the remaining transformations [2]
>> * change the default value of notification_format conf option from
>> 'both' to 'versioned'
>> * communicate that the legacy notification interface has been
>> deprecated, unsupported but the code will not be removed
>> 
>> Since the PTG the last two transformation patches [2] has been 
>> approved
>> and the deprecation patch has been prepared [3]. However recently we
>> got a bug report [4] where the performance impact of emiting both
>> legacy and versioned notification caused unnecessary load on the
>> message bus. (Btw this performance impact was raised in the original
>> spec [5]). The original reason we emited both type of notifications 
>> was
>> to keep backward compatibility with consumers only understanding 
>> legacy
>> notifications. It worked so well that most of the consumers still
>> depend on the legacy notifications (detailed status is in [1]).
>> 
>> I see three options to move forward:
>> 
>> A) Do nothing. By default, emit both type of notifications. This 
>> means
>> that deployers seeing the performance impact of [4] needs to
>> reconfigure nova. Also this is agains our decision to move away from
>> supporting legacy notifications.
>> 
>> B) Follow the plan from the PTG and change the default value of the
>> config to emit only versioned notifications. This solves the 
>> immediate
>> effect of the bug [4]. This is following our original plan. BUT this 
>> is
>> backward incompatible change which in the current situation means 
>> most
>> of the deployments (e.g. those, deploying notification consumer 
>> modules
>> like ceilometer) need to change this config to 'unversioned' or 
>> 'both'.
>> 
>> There was discussion about helping out notification consumers to
>> convert their code using the new versioned interface but I have no
>> spare time at the moment and I failed to drum up resources internally
>> for this work. Also I don't see others volunteering for such work.
>> 
>> C) Change the default to 'legacy'. This solves the bug [4]. BUT 
>> sends a
>> really mixed message. As our original goal was to stop supporting the
>> legacy notification interface of nova.
>> Matt stated on IRC recently, there is no real bug inflow for the 
>> legacy
>> code. Also looking at changes in the code I see that last cycle we 
>> had
>> couple of blueprints extending the new versioned notifications with
>> extra fields but that inflow stopped in this cycle too. So we most
>> probably can keep the legacy code in place and supported forever
>> without too much pain and too much divergence from the versioned
>> interface.
>> 
>> --
>> 
>> Personally, I spent enough time implementing and reviewing the
>> versioned interface that I'm biased towards option B). But I do
>> understand that our original goals setting in 2015 was made in such
>> environment that changed significantly in the past cycles. So I can
>> accept option C) as well if we can agree.
>> 
>> Cheers,
>> gibi
>> 
>> [1]https://etherpad.openstack.org/p/nova-ptg-stein  L765
>> [2]
>> https://review.openstack.org/#/q/topic:bp/versioned-notification-transformation-stein+status:open
>> [3]https://review.openstack.org/#/c/603079/
>> [4]https://bugs.launchpad.net/nova/+bug/1805659
>> [5]
>> https://review.openstack.org/#/c/224755/11/specs/mitaka/approved/versioned-notification-api.rst@687
> 
> In skimming the spec again:
> 
> https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/versioned-notification-transformation-newton.html
> 
> I get that legacy unversioned notifications in nova were kind of a 
> mess and changing them without a version was icky even though they 
> are internal to a deployment. Moving to using versioned notifications 
> with well-defined objects, docs samples, all of that is very nice for 
> nova *developers*, but what I've been struggling with is what benefit 
> do the versioned notifications bring to nova *consumers*, besides we 
> say you can only add new notifications if they are versioned.

Funnily, orignially I only wanted to add one new (legacy) notification 
(service.update) to nova back in 2015 and that requirement discussion 
led to the birth of the versioned interface.

But besides that, I think, discovering what notifications exists and 
what data is provided in any given notifications are someting that is 
lot easier now with the versioned interface for (new) consumers that 
don't want to read nova code. They just open the docs and the samples. 
Sure this is not a good reason for a consumer that did the legwork 
already and built something top of the legacy interface.

Are there new notification consumers apparing around nova? I don't 
think so. I guess we were naive enough three years ago to think that 
there will be new notification consumers to justify this work.

> 
> In other words, what motivation does a project that is currently 
> consuming unversioned legacy notifications have to put the work in to 
> switch to versioned notifications? The spec doesn't really get into 
> that in much detail.
> 
> I do remember an older thread with gordc where he was asking about 
> schema payloads and such so a consumer could say implement processing 
> a notification at version 1.0, but then if it gets a version 1.4 
> payload it could figure out how to backlevel the payload to the 1.0 
> version it understands - sort of like what we've talked about doing 
> with os-vif between nova and neutron (again, for years). But that 
> thread kind of died out from what I remember. But that seems like a 
> nice benefit for upgrades, but I also figure it's probably very low 
> priority on everyone's wishlist.

I agree. I don't see any benefit for well establised legacy 
notification consumer besides the discoverability of change in the 
payload schema. But that schema also does not change too much.

Cheers,
gibi

> 
> Another way I've thought about the deprecation lately is that if we 
> (nova devs) did the work to migrate ceilometer, then we'd have one 
> major consumer and we could then deprecate the legacy notifications 
> and change the default to 'versioned'. But like you said, no one is 
> coming out of the woodwork to do that work.
> 
> Anyway, I'm just having a hard time with the fact so much work has 
> been put into this over the last few years that now everything is 
> transformed but no one is using it, and I don't see many compelling 
> reasons why a project would migrate, especially since the projects 
> that are consuming nova's notifications are mostly working with a 
> skeleton crew of maintainers.
> 
> I'd really like some input from other project developers and 
> operators here.
> 
> --
> 
> Thanks,
> 
> Matt
> 




More information about the openstack-discuss mailing list